Some examples for `std::num::Float`
~~This is WIP for making examples for `f32`. This probably won't pass `make tidy` and I'm not sure which `f32` needs documentation. https://github.com/rust-lang/rust/issues/22025 shows 2 sets of `f32` which seems split between `core` and `std`. I'm not sure which should be documented but I started doing a couple from `std`. Easy to move if that's where they go...~~
~~Gotta build it eventually to actually see if the docs actually appear where I think they will or if I'm just disillusioned.~~
cc @steveklabnik
The test \"signal_reported_right\" send a signal `1` to `/bin/sh`, and check
the status code to check if the signal is reported right.
Under OpenBSD, the signal `1` (`SIGHUP`) is catched by `/bin/sh`,
resulting the test failed.
Use the uncatchable signal `9` (`SIGKILL`) for test.
This commit mostly replaces some of the uses of os::args with env::args.
This, for obvious reasons is based on top of #22400. Do not r+ before that lands.
The connect_error test check if connecting to "0.0.0.0:1" works (it
shouldn't). And in case of error, the test expects a ConnectionRefused
error.
Under OpenBSD, trying to connect to "0.0.0.0" isn't a ConnectionRefused:
it is an InvalidInput error.
The patch allow the error to be ConnectionRefused or InvalidInput.
Changes std::os::errno to return i32, the return type used by the function being delegated to.
This is my first contribution, so feel free to give me advice. I'll be happy to correct things.
`IntoIterator` now has an extra associated item:
``` rust
trait IntoIterator {
type Item;
type IntoIter: Iterator<Self=Self::Item>;
}
```
This lets you bind the iterator \"`Item`\" directly when writing generic functions:
``` rust
// hypothetical change, not included in this PR
impl Extend<T> for Vec<T> {
// you can now write
fn extend<I>(&mut self, it: I) where I: IntoIterator<Item=T> { .. }
// instead of
fn extend<I: IntoIterator>(&mut self, it: I) where I::IntoIter: Iterator<Item=T> { .. }
}
```
The downside is that now you have to write an extra associated type in your `IntoIterator` implementations:
``` diff
impl<T> IntoIterator for Vec<T> {
+ type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(self) -> IntoIter<T> { .. }
}
```
Because this breaks all downstream implementations of `IntoIterator`, this is a [breaking-change]
---
r? @aturon
This snuck through my refactor.
Would it be worth the effort to have a test pass that attempts to lint the code for all targets, even if it's not feasible to actually build and test it?
`pipe(2)`, under FreeBSD and OpenBSD return a bidirectionnal pipe. So
reading from the writer would block (waiting data) instead of returning
an error.
like for FreeBSD, disable the test for OpenBSD.
Rather than stabilize on the current API, we're going to punt this
concern to crates.io, to allow for faster iteration.
If you need this functionality, you might look at https://github.com/carllerche/syncbox
[breaking-change]
This commit exposes the `is_sep` function and `MAIN_SEP` constant, as
well as Windows path prefixes. The path prefix enum is safely exposed on
all platforms, but it only yielded as a component for Windows.
Exposing the prefix enum as part of prefix components involved changing
the type from `OsStr` to the `Prefix` enum, which is a:
[breaking-change]
The test "signal_reported_right" send a signal `1` to `/bin/sh`, and check
the status code to check if the signal is reported right.
Under OpenBSD, the signal `1` (`SIGHUP`) is catched by `/bin/sh`,
resulting the test failed.
Use the uncatchable signal `9` (`SIGKILL`) for test.
This PR replaces uses of `os::getenv` with newly introduced `env::var{,_os}`.
Mostly did this as a background activity to procrastinate from procrastinating.
Tests appear to build and run fine. This includes benchmarks from test/bench directory.
Some function signatures have changed, so this is a [breaking-change].
In particular, radixes and numerical values of digits are represented by `u32` now.
Part of #22240
`PathBuf` does implement `Hash`, but `Path` doesn't. This makes it
annoying if you have a `HashMap` with `PathBuf`s as keys, because
it means you have to convert a `Path` into a `PathBuf` and get a
reference to it simply to perform operations on the `HashMap`!
`PathBuf` does implement `Hash`, but `Path` doesn't. This makes it
annoying if you have a `HashMap` with `PathBuf`s as keys, because
it means you have to convert a `Path` into a `PathBuf` and get a
reference to it simply to perform operations on the `HashMap`!
Per [RFC 579](https://github.com/rust-lang/rfcs/pull/579), this commit
adds a new `std::process` module. This module is largely based on the
existing `std::old_io::process` module, but refactors the API to use
`OsStr` and other new standards set out by IO reform.
The existing module is not yet deprecated, to allow for the new API to
get a bit of testing before a mass migration to it.
