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.
library: Increase timeout on mpmc test to reduce flakes
This recently spuriously failed in a rollup, so I think we can afford to increase the base timeout and the amount of time slept for to provide a much wider margin for the timeout to be reached.
This recently spuriously failed in a rollup, so I think we can afford to
increase the base timeout and the amount of time slept for to provide
a much wider margin for the timeout to be reached.
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 :)
Remove "intermittent" wording from `ReadDir`
`ReadDir` claims that `next` will return an error "if there’s some sort of intermittent IO error during iteration". I'm really not sure what this was intended to mean but the implementations will simply return all OS errors encountered during iteration to the user. What else can they do?
This is technically a change in the documented API but seeing as how it doesn't bear any relationship with the implementation I don't think it needs a libs-api fcp.
Upgrade `object`, `addr2line`, and `unwinding` in the standard library
Object:
0.37.0 is a semver-breaking release but the only breakage is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld. This API is not used by `std`, so we should be fine to upgrade.
This new version also includes functionality for parsing Wasm object files that we may eventually like to make use of.
Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Addr2line:
0.25.0 is a breaking change only because it upgrades the `gimli` version. It also includes a change to the `compiler-builtins` dependency that helps with [1].
Changelog: https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md#0250-20250611
[1]: https://github.com/rust-lang/rust/issues/142265
0.37.0 is a semver-breaking release but the only breakage is in
`elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as
Mach-O dyld. This API is not used by `std`, so we should be fine to
upgrade.
This new version also includes functionality for parsing Wasm object
files that we may eventually like to make use of.
Also includes the minor bump from 0.37.0 to 0.37.1 to help [1].
Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
[1]: https://github.com/rust-lang/rust/issues/142265
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
