| Age | Commit message (Collapse) | Author | Lines |
|---|
|
I'm not sure why this is failing. This patch disables this test until I can figure out what is wrong.
|
|
Seeking the `BufWriter` writes out its internal buffer before seeking.
|
|
Seeking the `BufReader` discards the internal buffer (and adjusts the
offset appropriately when seeking with `SeekFrom::Current(_)`).
|
|
This commit stabilizes the old `io::Error::from_os_error` after being renamed to
use the `raw_os_error` terminology instead. This function is often useful when
writing bindings to OS functions but only actually converting to an I/O error at
a later point.
|
|
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.
[breaking-change]
cc #24208
|
|
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
I’m not sure whether we want to do this change, though, because it has the same deadlock hazard which we tried to avoid by not locking inside write_fmt itself (see [this comment](https://github.com/rust-lang/rust/blob/80def6c2447d23a624e611417f24cf0ab2a5a676/src/libstd/io/stdio.rs#L267)).
Spotted on [reddit].
cc @alexcrichton
[reddit]: http://www.reddit.com/r/rust/comments/31comh/println_with_multiple_threads/
|
|
The current implementation of using GetFinalPathNameByHandle actually reads all
intermediate links instead of just looking at the current link. This commit
alters the behavior of the function to use a different API which correctly reads
only one level of the soft link.
[breaking-change]
|
|
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
This patch implements reentrant mutexes, changes stdio handles to use these mutexes and overrides
write_fmt to lock the stdio handle for the whole duration of the call.
|
|
r=steveklabnik
As beta is now released and is "suggested" version of `rustc` then there should be no code (in documentation) that will not compile with it. This one does not.
So according to [this great talk](http://delete-your-code.herokuapp.com/), I am doing what should be done.
|
|
Make the structure more amenable to what rustdoc is expecting to ensure that
everything renders all nice and pretty in the output.
Closes #23705
Closes #23910
|
|
Allow a few specific ones but otherwise this helps ensure that our examples are
squeaky clean!
Closes #18199
|
|
Previously it could not be implemented for types outside `libcore/iter.rs` due
to coherence issues.
|
|
|
|
In addition to being nicer, this also allows you to use `sum` and `product` for
iterators yielding custom types aside from the standard integers.
Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this
is a breaking change.
[breaking-change]
|
|
|
|
|
|
There is no `read_string` function, and `lines` never returns an error.
|
|
working 100%
|
|
from https://news.ycombinator.com/item?id=9317822
|
|
|
|
from https://news.ycombinator.com/item?id=9317822
|
|
These constants are small and can fit even in `u8`, but semantically they have type `usize` because they denote sizes and are almost always used in `usize` context. The change of their type to `u32` during the integer audit led only to the large amount of `as usize` noise (see the second commit, which removes this noise).
This is a minor [breaking-change] to an unstable interface.
r? @aturon
|
|
|
|
|
|
I also wanted to unignore https://github.com/rust-lang/rust/blob/master/src/libsyntax/ext/expand.rs#L1768-L1777 since the issue it references is closed, but the test fails, and it's internals aren't super clear to me.
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/test/compile-fail/coherence-impls-copy.rs
|
|
Feature-gate unsigned unary negate.
Discussed in weekly meeting here: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-03-31.md#feature-gate--expr
and also in the internals thread here: http://internals.rust-lang.org/t/forbid-unsigned-integer/752
|
|
Conflicts:
src/libcore/num/mod.rs
|
|
This commit renames and stabilizes:
* `Condvar::wait_timeout_ms` (renamed from `wait_timeout`)
* `thread::park_timeout_ms` (renamed from `park_timeout`)
* `thread::sleep_ms` (renamed from `sleep`)
In each case, the timeout is taken as a `u32` number of milliseconds,
rather than a `Duration`.
These functions are likely to be deprecated once a stable form of
`Duration` is available, but there is little cost to having these named
variants around, and it's crucial functionality for 1.0.
[breaking-change]
r? @alexcrichton
cc @sfackler @carllerche
|
|
This commit renames and stabilizes:
* `Condvar::wait_timeout_ms` (renamed from `wait_timeout`)
* `thread::park_timeout_ms` (renamed from `park_timeout`)
* `thread::sleep_ms` (renamed from `sleep`)
In each case, the timeout is taken as a `u32` number of milliseconds,
rather than a `Duration`.
These functions are likely to be deprecated once a stable form of
`Duration` is available, but there is little cost to having these named
variants around, and it's crucial functionality for 1.0.
[breaking-change]
|
|
|
|
Conflicts:
src/liballoc/boxed.rs
|
|
This commit is an implementation of [RFC 979][rfc] which changes the meaning of
the count parameter to the `splitn` function on strings and slices. The
parameter now means the number of items that are returned from the iterator, not
the number of splits that are made.
[rfc]: https://github.com/rust-lang/rfcs/pull/979
Closes #23911
[breaking-change]
|
|
This commit is an implementation of [RFC 979][rfc] which changes the meaning of
the count parameter to the `splitn` function on strings and slices. The
parameter now means the number of items that are returned from the iterator, not
the number of splits that are made.
[rfc]: https://github.com/rust-lang/rfcs/pull/979
Closes #23911
[breaking-change]
|
|
|
|
This PR implements rust-lang/rfcs#1023. In the process it fixes #23086 and #23516. A few impls in libcore had to be updated, but the impact is generally pretty minimal. Most of the fallout is in the tests that probed the limits of today's coherence.
I tested and we were able to build the most popular crates along with iron (modulo errors around errors being sendable).
Fixes #23918.
|
|
sidesteps a coherence difficulty where `liballoc` had to prove that
`&str: !Error`, which didn't involve any local types.
|
|
|
|
This introduces no functional changes except for reducing a few unnecessary operations and variables. Vec has the behavior that, if you request space past the capacity with reserve(), it will round up to the nearest power of 2. What that effectively means is that after the first call to reserve(16), we are doubling our capacity every time. So using the DEFAULT_BUF_SIZE and doubling cap_size() here is meaningless and has no effect on the call to reserve().
Note that with #23842 implemented this will hopefully have a clearer API and less of a need for commenting. If #23842 is not implemented then the most clear implementation would be to call reserve_exact(buf.capacity()) at every step (and making sure that buf.capacity() is not zero at the beginning of the function of course).
Edit- functional change now introduced. We will now zero 16 bytes of the vector first, then double to 32, then 64, etc. until we read 64kB. This stops us from zeroing the entire vector when we double it, some of which may be wasted work. Reallocation still follows the doubling strategy, but the responsibility has been moved to vec.extend(), which calls reserve() and push_back().
|
|
for `Box<FnBox()>`. I found the alias was still handy because it is
shorter than the fully written type.
This is a [breaking-change]: convert code using `Invoke` to use `FnBox`,
which is usually pretty straight-forward. Code using thunk mostly works
if you change `Thunk::new => Box::new` and `foo.invoke(arg)` to
`foo(arg)`.
|
|
comment includes a test that also shows how it can be used.
|
|
This issue is long closed. It seems that unwrapping will always panic
though.
|
|
|
|
|
|
|
|
|
