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
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]
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.
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
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
unix. A windows implementation is coming in a later commit.
The clone implementation is based on atomic reference counting (as with all
other clones), and the close_accept implementation is based on selecting on a
self-pipe which signals that a close has been seen.
This enables `num_milliseconds` to return an `i64` again instead of
`Option<i64>`, because it is guaranteed not to overflow.
The Duration range is now rougly 300e6 years (positive and negative),
whereas it was 300e9 years previously. To put these numbers in
perspective, 300e9 years is about 21 times the age of the universe
(according to Wolfram|Alpha). 300e6 years is about 1/15 of the age of
the earth (according to Wolfram|Alpha).
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves#16466. 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.
