Implementation: `#[feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::condvar`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`.
There are two other changes here. The first is that the `Barrier` implementation is migrated to use the `nonpoison::Condvar` instead of the `poison` variant. The second (which might be subject to some discussion) is that `WaitTimeoutResult` is moved up to `mod.rs`, as both `condvar` variants need that type (and I do not know if there is a better place to put it now).
### Related PRs
- `nonpoison_rwlock` implementation: https://github.com/rust-lang/rust/pull/144648
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
fix(lib-std-fs): handle `usize` overflow in `read*`
I assume this is a non-breaking change, as there would be an OOM `panic` anyways. This patch ensures a fast-fail when there's not enough memory to load the file. This only changes behavior on platforms where `usize` is smaller than 64bits
fix(std): Fix undefined reference to __my_thread_exit on QNX 8.0
When cross-compiling for the x86_64/aarch64-unknown-nto-qnx800 target (QNX SDP 8.0), the build fails during the final link stage with the error:
```
error: linking with `qcc` failed: exit status: 1
...
= note: undefined reference to `__my_thread_exit'
```
- **On QNX 7.1**: The __my_thread_exit symbol is defined and exported by the main C library (libc.a/libc.so). The std backtrace code can therefore successfully take its address at compile time.
- **On QNX 8.0**: As part of a toolchain modernization, this symbol has been refactored. It is no longer present in any of the standard system libraries (.a or .so).
This patch addresses the problem at its source by conditionally compiling the problematic code.
Fixesrust-lang/rust#142726
`const`ify (the unstable) `str::as_str`
Tracking issue: rust-lang/rust#130366
The method was not initially marked `const` presumably because it is only useful with `Deref`. But now that const traits seem to be a thing that can actually become real, why not make it `const`?
PR `const`ifying `Deref`: rust-lang/rust#145279
Rename `Location::file_with_nul` to `file_as_c_str`
This renames the method to be consistent with the ongoing T-libs-api FCP found at https://github.com/rust-lang/rust/issues/141727#issuecomment-3228016708.
I did not rename the unstable feature as we are going to be stabilizing it soon anyway. This will probably break RfL, so it will require an updated commit hash for the Linux Kernel that I will add here soon.
r? `@Amanieu`
Fix STD build failing for target_os = "espidf"
A regression from rust-lang/rust#142938
cc `@lolbinarycat`
cc `@ibraheemdev`
ESP-IDF (and a few other embedded Tier-3 systems) is considered `cfg(unix)`, but it does not have the `O_NOFOLLOW` flag because neither of its three supported filesystems (FATFS, LitteLF and Spiffs) has symbolic links in the first place.
What this fix does is to keep the `set_permissions_nofollow` method available and non-failing for ESP-IDF, but it behaves as if no `O_NONFOLLOW` was set. This should be fine as there is nothing to follow in the first place, as there are no symbolic links there.
EDIT: Also added the same fix for Horizon, as requested by `@Meziu.`
improve float to_degrees/to_radians rounding comments and impl
This PR makes `to_degrees()` and `to_radians()` float functions more consistent between each other and improves comments around their precision and rounding.
* revise comments explaining why we are using literal or expression
* add unspecified precision comments as we don't guarantee precision
* use expression in `f128::to_degrees()`
* make `f64::to_degrees()` impl consistent with other functions
r? `@tgross35`
Simplify macro generating ToString implementations for `&…&str`
Use deref coercion to let the compiler remove any amount of references. Also use that macro for `Cow` and `String`.
Move WTF-8 code from std into core and alloc
This is basically a small portion of rust-lang/rust#129411 with a smaller scope. It *does not*\* affect any public APIs; this code is still internal to the standard library. It just moves the WTF-8 code into `core` and `alloc` so it can be accessed by `no_std` crates like `backtrace`.
> \* The only public API this affects is by adding a `Debug` implementation to `std::os::windows::ffi::EncodeWide`, which was not present before. This is due to the fact that `core` requires `Debug` implementations for all types, but `std` does not (yet) require this. Even though this was ultimately changed to be a wrapper over the original type, not a re-export, I decided to keep the `Debug` implementation so it remains useful.
Like we do with ordinary strings, the tests are still located entirely in `alloc`, rather than splitting them into `core` and `alloc`.
----
Reviewer note: for ease of review, this is split into three commits:
1. Moving the original files into their new "locations"
2. Actually modifying the code to compile.
3. Removing aesthetic changes that were made so that the diff for commit 2 was readable.
You can review commits 1 and 3 to verify these claims, but commit 2 contains the majority of the changes you should care about.
----
API changes: `impl Debug for std::os::windows::ffi::EncodeWide`
Improve std::fs::read_dir docs
Call out early that the results returned can differ across calls / aren't deterministic. This was already mentioned at the bottom of examples, but I think it's worth calling out early, since this caused at least one person (me!) great confusion.
Call out early that the results returned can differ across calls /
aren't deterministic. This was already mentioned at the bottom of
examples, but I think it's worth calling out early, since this caused at
least one person (me!) great confusion.
[ Added a comma to the docs, reflowed commit message - Trevor ]
formatting_options: Make all methods `const`
Related to rust-lang/rust#118117.
Having `const fn`s that take a `mut &` was unstable until Rust 1.83 (see rust-lang/rust#129195). Because of this, not all methods on `FormattingOptions` were implemented as `const`. As this has been stabilized now, there is no reason not to have all methods `const`.
Thanks to `@Ternvein` for bringing this to my attention (see [1]).
r? `@m-ou-se` (As you were the reviewer for the original implementation – feel free to reroll if you are busy or if you aren't interested)
[1]: https://github.com/rust-lang/rust/issues/118117#issuecomment-2687470635
Having `const fn`s that take a `mut &` was unstable until Rust 1.83. Because of
this, not all methods on `FormattingOptions` were implemented as `const`. As
this has been stabilized now, there is no reason not to have all methods
`const`.
Thanks to Ternvein for bringing this to my attention (see [1]).
[1]: https://github.com/rust-lang/rust/issues/118117#issuecomment-2687470635
Extend the <target>.optimized-compiler-builtins bootstrap option to accept a
path to a prebuilt compiler-rt builtins library, and update compiler-builtins
to enable optimized builtins without building compiler-rt builtins.
Dial down detail of B-tree description
fixes#134088, though it is a shame to lose some of this wonderful detail.
r? `@workingjubilee`
EDIT: newest versions keep old detail, but move it down a bit.
This commit adds an empty stub for the function
for QNX 8 targets. This symbol is required by the unwinder but is
not present, causing a linking failure when building with the
standard library.
Address review feedback: use whitelist for QNX versions
Add lint against integer to pointer transmutes
# `integer_to_ptr_transmutes`
*warn-by-default*
The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference.
### Example
```rust
fn foo(a: usize) -> *const u8 {
unsafe {
std::mem::transmute::<usize, *const u8>(a)
}
}
```
```
warning: transmuting an integer to a pointer creates a pointer without provenance
--> a.rs:1:9
|
158 | std::mem::transmute::<usize, *const u8>(a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is dangerous because dereferencing the resulting pointer is undefined behavior
= note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance
= help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut`
= help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers>
= help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance>
= note: `#[warn(integer_to_ptr_transmutes)]` on by default
help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance
|
158 - std::mem::transmute::<usize, *const u8>(a)
158 + std::ptr::with_exposed_provenance::<u8>(a)
|
```
### Explanation
Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance.
Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used.
See [std::mem::transmute] in the reference for more details.
[std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
--------
People are getting tripped up on this, see https://github.com/rust-lang/rust/issues/128409 and https://github.com/rust-lang/rust/issues/141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code).
Fixes https://github.com/rust-lang/rust-clippy/issues/13140
Fixes https://github.com/rust-lang/rust/issues/141220
Fixes https://github.com/rust-lang/rust/issues/145523
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
