Most of this is platform-specific anyway, and we generally have to jump through
fewer hoops to do the equivalent operation on Windows. One benefit for Windows
today is that this new structure avoids an extra `DuplicateHandle` when creating
pipes. For Unix, however, the behavior should be the same.
Note that this is just a pure refactoring, no functionality was added or
removed.
The function `CreateProcess` is not itself unsafe to call from many threads, the
article in question is pointing out that handles can be inherited by unintended
child processes. This is basically the same race as the standard Unix
open-then-set-cloexec race.
Since the intention of the lock is to protect children from inheriting
unintended handles, the lock is now lifted out to before the creation of the
child I/O handles (which will all be inheritable). This will ensure that we only
have one process in Rust at least creating inheritable handles at a time,
preventing unintended inheritance to children.
On Unix we have to be careful to not call `waitpid` twice, but we don't have to
be careful on Windows due to the way process handles work there. As a result the
cached `Option<ExitStatus>` is only necessary on Unix, and it's also just an
implementation detail of the Unix module.
At the same time. also update some code in `kill` on Unix to avoid a wonky
waitpid with WNOHANG. This was added in 0e190b9a to solve #13124, but the
`signal(0)` method is not supported any more so there's no need to for this
workaround. I believe that this is no longer necessary as it's not really doing
anything.
This is a Unix-specific function which adds the ability to register a closure to
run pre-exec to configure the child process as required (note that these
closures are run post-fork).
cc #31398
* Build up the argp/envp pointers while the `Command` is being constructed
rather than only when `spawn` is called. This will allow better sharing of
code between fork/exec paths.
* Rename `child_after_fork` to `exec` and have it only perform the exec half of
the spawning. This also means the return type has changed to `io::Error`
rather than `!` to represent errors that happen.
A spec like `#[cfg(foo(bar))]` is not allowed as an attribute. This
makes the same spec be rejected by the compiler if passed in as a
`--cfg` argument.
Fixes#31495
collections: Use slice parts in PartialEq for VecDeque
This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.
```
test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s
test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s
```
The compiler currently vendors its own version of "llvm-ar" (not literally the
binary but rather the library support) and uses it for all major targets by
default (e.g. everything defined in `src/librustc_back/target`). All custom
target specs, however, still search for an `ar` tool by default. This commit
changes this default behavior to using the internally bundled llvm-ar with the
GNU format.
Currently all targets use the GNU format except for OSX which uses the BSD
format (surely makes sense, right?), and custom targets can change the format
via the `archive-format` key in custom target specs.
I suspect that we can outright remove support for invoking an external `ar`
utility, but I figure for now there may be some crazy target relying on that so
we should leave support in for now.
After [considerable pushback](https://github.com/rust-lang/rfcs/issues/1451), it's clear that there is a community consensus around providing `IpAddr` in the standard library, together with other APIs using it.
This commit reverts from deprecated status directly to stable. The deprecation landed in 1.6, which has already been released, so the stabilization is marked for 1.7 (currently in beta; will require a backport).
r? @alexcrichton
This commit does two things:
* Re-works the module-level documentation.
* Cleaning up wording and adding links to where error types are used.
Part of #29364
This commit does two things:
* Re-works the module-level documentation.
* Cleaning up wording and adding links to where error types are used.
Part of #29364
After [considerable
pushback](https://github.com/rust-lang/rfcs/issues/1451), it's clear
that there is a community consensus around providing `IpAddr` in the
standard library, together with other APIs using it.
This commit reverts from deprecated status directly to stable. The
deprecation landed in 1.6, which has already been released, so the
stabilization is marked for 1.7 (currently in beta; will require a backport).
Since a lexicographic ordering of a struct could vary based on which struct members are compared first, I ended up doing some testing to ensure that the behavior when deriving these traits was what I expected (ordered based on the top to bottom order of declaration of the members). I wanted to add this little bit of documentation to potentially save someone else the same effort. That is, assuming that my testing correctly reflects the intended behavior of the compiler.
r? @steveklabnik
The comment in the next line was already talking about `_guard`, and the scope guard a couple lines further down is also called `guard`, so I assume that was just a typo.
r? @steveklabnik
When I last did a pass through the string documentation, I focused on
consistency across similar functions. Unfortunately, I missed some
details. This example was _too_ consistent: it wasn't actually accurate!
This commit fixes the docs do both be more accurate and to explain why
the return type is a Cow<'a, str>.
First reported here:
https://www.reddit.com/r/rust/comments/44q9ms/stringfrom_utf8_lossy_doesnt_return_a_string/
This commit is an implementation of the new compiler flags required by [RFC
1361][rfc]. This specifically adds a new `cfg` option to the `--print` flag to
the compiler. This new directive will print the defined `#[cfg]` directives by
the compiler for the target in question.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1361-cargo-cfg-dependencies
This commit is an implementation of the new compiler flags required by [RFC
1361][rfc]. This specifically adds a new `cfg` option to the `--print` flag to
the compiler. This new directive will print the defined `#[cfg]` directives by
the compiler for the target in question.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1361-cargo-cfg-dependencies.md
The documentation for the `make_mut` function on `Arc<T>` contains a somewhat impenetrable double-negative that I was only able to fully grasp by looking at the implementation. Here's a quick rewrite that reads a lot better.
The sentence "doesn't have one strong reference and no weak references." is a
hard to understand, and it can be much more easily explained. In particular, such a double-negative
could give English as a Second Language users even more trouble than native speakers.
r? @steveklabnik
A spec like `#[cfg(foo(bar))]` is not allowed as an attribute. This
makes the same spec be rejected by the compiler if passed in as a
`--cfg` argument.
Fixes#31495
