Fix doc comment of File::try_lock and File::try_lock_shared
The doc comments of functions `File::try_lock` and `File::try_lock_shared` stabilized today in version 1.89.0 document an incorrect type of `Ok`.
The result type was changed in rust-lang/rust#139343 after the latest change to the doc comments in rust-lang/rust#136876.
compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled
Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled.
Enabling LSE is the primary motivator for rust-lang/rust#143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE.
r? ```````@tgross35```````
bump bootstrap compiler to 1.90 beta
There were significantly less `cfg(bootstrap)` and `cfg(not(bootstrap))` this release. Presumably due to the fact that we change the bootstrap stage orderings to reduce the need for them and it was successful 🙏
Miri: non-deterministic floating point operations in `foreign_items`
Part of [rust-lang/miri/#3555](https://github.com/rust-lang/miri/issues/3555#issue-2278914000), this pr does the `foreign_items` work.
Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added.
Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`.
I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as:
```
Returns
The sinh functions return sinh x.
```
So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
Print thread ID in panic message
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: dist-apple-various
try-job: dist-various-*
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: dist-x86_64-solaris
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-mingw-1
try-job: x86_64-msvc-1
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
add code example showing that file_prefix treats dotfiles as the name of a file, not an extension
This came up in a libs-api meeting while we were reviewing rust-lang/rust#144870
Change visibility of Args new function
Currently the Args new function is constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
This pull request is to change this to pub.
Create a private module to hold the bootstrap code needed enable LSE
at startup on aarch64-*-linux-* targets when rust implements the
intrinsics.
This is a bit more heavyweight than compiler-rt's LSE initialization,
but has the benefit of initializing the aarch64 cpu feature detection
for other uses.
Using the rust initialization code does use some atomic operations,
that's OK. Mixing LSE and non-LSE operations should work while the
update flag propagates.
Document Poisoning in `LazyCell` and `LazyLock`
Currently, there is no documentation of poisoning behavior in either `LazyCell` or `LazyLock`, even though both of them can be observed as poisoned by users.
`LazyCell` [plagyround example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9cf38b8dc56db100848f54085c2c697d)
`LazyLock` [playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f1cd6f9fe16636e347ebb695a0ce30c0)
# Open Questions
- [x] Is it worth making the implementation of `LazyLock` more complicated to ensure that the the panic message is `"LazyLock instance has previously been poisoned"` instead of `"Once instance has previously been poisoned"`? See the `LazyLock` playground link above for more context.
- [x] Does it make sense to move `LazyLock` into the `poison` module? It is certainly a poison-able type, but at the same time it is slightly different from the 4 other types currently in the `poison` module in that it is unrecoverable. I think this is more of a libs-api question.
``@rustbot`` label +T-libs-api
Please let me know if these open questions deserve a separate issue / PR!
UEFI networking APIs do support vectored read/write. While the types for
UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially
the same C struct. So we can map IoSlice and IoSliceMut to have the same
binary representation.
Since all UEFI networking types for read/write are DSTs, `IoSlice` and
`IoSliceMut` will need to be copied to the end of the transmit/receive
structures. So having the same binary representation just allows us to
do a single memcpy instead of having to loop and set the DST.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Remove unnecessary `rust_` prefixes
part of https://github.com/rust-lang/rust/issues/116005
Honestly, not sure if this can affect linking somehow, also I didn't touched things like `__rust_panic_cleanup` and `__rust_start_panic` which very likely will break something, so just small cleanup here
also didn't changed `rust_panic_without_hook` because it was renamed here https://github.com/rust-lang/rust/pull/144852
r? libs
Improve formatting of doc code blocks
We don't currently apply automatic formatting to doc comment code blocks. As a
result, it has built up various idiosyncracies, which make such automatic
formatting difficult. Some of those idiosyncracies also make things harder for
human readers or other tools.
This PR makes a few improvements to doc code formatting, in the hopes of making
future automatic formatting easier, as well as in many cases providing net
readability improvements.
I would suggest reading each commit separately, as each commit contains one
class of changes.
Document guarantees of poisoning
This mostly documents the current behavior of `Mutex` and `RwLock` (rust-lang/rust#143471) as imperfect. It's unlikely that the situation improves significantly in the future, and even if it does, the rules will probably be more complicated than "poisoning is completely reliable", so this is a conservative guarantee.
We also explicitly specify that `OnceLock` never poisons, even though it has an API similar to mutexes.
Fixesrust-lang/rust#143471 by improving documentation.
r? ``@Amanieu``
`compiler-builtins` is already in the crate graph via `alloc`, and all
features related to `compiler-builtins` goes through `alloc`. There
isn't any reason that `std` needs this direct dependency, so remove it.
`compiler_builtins` shouldn't be called directly. Change the `PartialEq`
implementation for `DevicePathNode` to use slice equality instead, which
will call `memcmp`/`bcmp` via the intrinsic.
thread name in stack overflow message
Fixesrust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`
Continuation of https://github.com/rust-lang/rust/pull/134663
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock.
There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests.
For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`).
Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`.
The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped.
~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
Adds tests for the `nonpoison::Mutex` variant by using a macro to
duplicate the existing `poison` tests.
Note that all of the tests here are adapted from the existing `poison`
tests.
