Workaround for memory unsafety in third party DLLs
Resolvesrust-lang/rust#143078
Note that we can't make any guarantees if third parties intercept OS functions and don't implement them according to the documentation. However, I think it's practical to attempt mitigations when issues are encountered in the wild and the mitigation itself isn't too invasive.
update internal `send_signal` comment
the vxwork did not have the old comment updated in rust-lang/rust#141990 so update here;
signaling -> sending signals to because the latter reads better to me.
std::net: adding `unix_socket_exclbind` feature for solaris/illumos.
allows to have a tigher control over the binding exclusivness of the socket.
ACP: https://github.com/rust-lang/libs-team/issues/366
Fix RwLock::try_write documentation for WouldBlock condition
Fix RwLock::try_write documentation for WouldBlock condition
The documentation incorrectly stated that try_write only fails when
'already locked exclusively', but it actually fails when there are
either shared (read) or exclusive (write) locks.
Fixesrust-lang/rust#142852
Windows: make `read_dir` stop iterating after the first error is encountered
This also essentially makes the `ReadDir` iterator fused. Which I think is pretty much what people expect anyway.
[`FindNextFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilew) doesn't document what happens if you call it after iteration ends or after an error so we're probably in implementation defined territory at that point.
Remove the deprecated unstable `concat_idents!` macro
In [rust-lang/rust#137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
#ident_to_str[]"). The syntax looks a bit different but it still works
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://github.com/rust-lang/rust/issues/29599
[rust-lang/rust#137653]: https://github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://github.com/rust-lang/rust/issues/124225
In [137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://www.github.com/rust-lang/rust/issues/29599
[137653]: https://www.github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://www.github.com/rust-lang/rust/issues/124225
Implement send_signal for unix child processes
Tracking issue: rust-lang/rust#141975
There are two main differences between my implementation and the Public API section of the tracking issue. ~First, `send_signal` requires a mutable reference, like `Child::kill`.~ Second, `ChildExt` has `Sealed` as a supertrait, bringing it more in line with other extension traits like `CommandExt`.
try-job: `dist-various*`
try-job: `test-various*`
Handle win32 separator for cygwin paths
This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters.
r? `@mati865`
cc `@jeremyd2019`
~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~
Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths.
UPDATE: Windows path prefix is handled.
Windows: Use anonymous pipes in Command
When setting `Stdio::pipe` on `Command` we want to create an anonymous pipe that can be used asynchronously (at least on our end). Usually we'd use [`CreatePipe`](https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createpipe) to open anonymous pipes but unfortunately it opens pipes for synchronous access. The alternative is to use [`CreateNamedPipeW`](https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-createnamedpipew) which does allow asynchronous access but that requires giving a file name to the pipe. So we currently have this awful hack where we attempt to emulate anonymous pipes using `CreateNamedPipeW` by attempting to create a unique name and looping until we find one that doesn't already exist.
The better option is to use the lower level [`NtCreateNamedPipeFile`](https://learn.microsoft.com/en-us/windows/win32/devnotes/nt-create-named-pipe-file) (which is used internally by both `CreatePipe` and `CreateNamedPipeW`). This function wasn't documented until a few years ago but now that it is it's ok for us to use it.
try-job: *msvc*
try-job: *mingw*
Add documentation for `PathBuf`'s `FromIterator` and `Extend` impls
I think it's not very obvious that `PathBuf`'s `Extend` and `FromIterator` impls work like `PathBuf::push`, so I think these should be documented.
I'm not very happy with the wording and examples, open to suggestions :)
docs: Small clarification on the usage of read_to_string and read_to_end trait methods
Small clarification on the usage of read_to_string and read_to_end trait methods. The goal is to make it clear that these trait methods will become locked up if attempting to read to the end of stdin (which is a bit non-sensical unless the other end closes the pipe).
Fixes: rust-lang/rust#141714
Enable Non-determinism of float operations in Miri and change std tests
Links to [#4208](https://github.com/rust-lang/miri/issues/4208) and [#3555](https://github.com/rust-lang/miri/issues/3555) in Miri.
Non-determinism of floating point operations was disabled in rust-lang/rust#137594 because it breaks the tests and doc-tests in core/coretests and std. This PR enables some of them.
This pr includes the following changes:
- Enables the float non-determinism but with a lower relative error of 4ULP instead of 16ULP
- These operations now have a fixed output based on the C23 standard, except the pow operations, this is tracked in [#4286](https://github.com/rust-lang/miri/issues/4286#issue-3010677983)
- Changes tests that made incorrect assumptions about the operations, not to make that assumption anymore (from `assert_eq!` to `assert_approx_eq!`.
- Changed the doctests of the stdlib of these operations to compare against fixed constants instead of `f*::EPSILON`, which now succeed with Miri and `-Zmiri-many-seeds`
- Added a constant `APPROX_DELTA` in `std/tests/floats/f32.rs` which is used for approximation tests, but with a different value when run in Miri. This is to make these tests succeed.
- Added tests in the float tests of Miri to test the C23 behaviour.
Fixes https://github.com/rust-lang/miri/issues/4208
De-duplicate f16 & f128 doctest attributes
Now that rustdoc supports `#[doc(test(attr(...)))]` at every level, thanks to https://github.com/rust-lang/rust/pull/140560, we can de-duplicate the f16 & f128 doctest attributes.
Unfortunately we can de-duplicate the `cfg`s attribute as rustdoc would complain about missing `main`, but it's already much better than before.
Addresses https://github.com/rust-lang/rust/pull/140323/files#r2062702761
r? `@tgross35`
Stabilize `tcp_quickack`
to stabilise the quickack part for now, tcp_deferaccept had been added at a later stage.
The related API calls are the following
```rust
// std::os::linux::net
// sealed trait, implemented for std::net::TcpStream
pub trait TcpStreamExt: Sealed{
fn quickack(&self) -> io::Result<bool>;
fn set_quickack(&self, quickack: bool) -> io::Result<()>;
}
```
Closes: https://github.com/rust-lang/rust/issues/96256
unsafe keyword docs: emphasize that an unsafe fn in a trait does not get to choose its safety contract
Inspired by discussion in https://github.com/rust-lang/rust/issues/139368.
Cc `@hanna-kruppe`
Reexport types from `c_size_t` in `std`
These are unstably available in `core` and should be in `std` too, but are not currently reexported. Resolve this here.
Tracking issue: https://github.com/rust-lang/rust/issues/88345
