| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This test has recently been failing on the bots, and I'm not entirely sure why.
I haven't been able to reproduce locally or on the bots, so I'm adding some
messages to help diagnose the problem hopefully.
|
|
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
|
|
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.
[breaking-change]
|
|
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
[breaking-change]
|
|
In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.
Fixes #17617
|
|
In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.
Fixes #17617
|
|
|
|
|
|
cc #17490
Reopening of #16230
|
|
over inherent methods accessible via more autoderefs.
This simplifies the trait matching algorithm. It breaks code like:
impl Foo {
fn foo(self) {
// before this change, this will be called
}
}
impl<'a,'b,'c> Trait for &'a &'b &'c Foo {
fn foo(self) {
// after this change, this will be called
}
}
fn main() {
let x = &(&(&Foo));
x.foo();
}
To explicitly indicate that you wish to call the inherent method, perform
explicit dereferences. For example:
fn main() {
let x = &(&(&Foo));
(***x).foo();
}
Part of #17282.
[breaking-change]
|
|
|
|
|
|
Replace `#[ignore(cfg(a, b))]` with `#[cfg_attr(all(a, b), ignore)]`
|
|
|
|
|
|
Closes #16937
|
|
|
|
|
|
|
|
|
|
As per [RFC
52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md),
use `_mut` suffixes to mark mutable variants, and `into_iter` for moving
iterators.
[breaking-change]
|
|
Renamed as we may support pipes for other platforms.
Closes #12093
[breaking-change]
|
|
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Change this code to:
use std::io::fs::PathExtensions;
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Closes #17059.
RFC #155.
[breaking-change]
|
|
I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 10000 which the included links in the added comment end up
recommending.
It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
|
|
I've found that 64k is still too much and continue to see the errors as reported
in #14940. I've locally found that 32k fails, and 24k succeeds, so I've trimmed
the size down to 8192 which libuv happens to use as well.
It sounds like the limit can still be hit with many threads in play, but I have
yet to reproduce this, so I figure we can wait until that's hit (if it's
possible) and then take action.
|
|
Closes #16880.
|
|
This allows using `try!()`
[breaking-change]
Fixes #16875
|
|
Cargo needs this to be able to instantiate `TerminfoTerminal<Box<Writer+'a>>` for 'a other than 'static.
|
|
Closes #16469
|
|
r=alexcrichton
I corrected spelling and capitalization errors in comments and strings.
|
|
This looks nicer because it reflects Rust's other syntactic structures.
|
|
Closes #16943.
|
|
|
|
|
|
Closes #16943.
|
|
Closes #15349
[breaking-change]
Trait objects are no longer implicitly coerced from Box<T> to &T. You must make an explicit coercion using `&*`.
|
|
This allows using `try!()`
[breaking-change]
Fixes #16875
|
|
|
|
Cargo needs this to be able to instantiate `TerminfoTerminal<Box<Writer+'a>>`
for 'a other than 'static.
|
|
Per API meeting
https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md
# Changes to `core::option`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.
# Changes to `core::result`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.
Due to deprecations, this is a:
[breaking-change]
|
|
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.
A few remarks:
- Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour?
- In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?
- Negative durations are not formatted correctly, but they were not formatted correctly before either.
|
|
|
|
|
|
|
|
This commits takes a similar strategy to the previous commit to implement
close_accept and clone for the native win32 pipes implementation.
Closes #15595
|
