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.
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
std/sys/fd: Relax `READ_LIMIT` on Darwin
Darwin's `read`/`write` syscalls emit `EINVAL` only when `nbyte > INT_MAX`. The case `nbyte == INT_MAX` is valid, so the subtraction (`- 1`) in
```rust
const READ_LIMIT: usize = if cfg!(target_vendor = "apple") {
libc::c_int::MAX as usize - 1 // <- HERE
} else {
libc::ssize_t::MAX as usize
};
```
can be removed.
I tested that the case `nbyte == INT_MAX` is valid on various versions of macOS, including old one like Mac OS X 10.5.
The man page says:
- read() and pread() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/read.2.html)
- write() and pwrite() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/write.2.html)
Here are links to Darwin's code:
- [macOS 15.5] e3723e1f17/bsd/kern/sys_generic.c (L307)
- [Mac OS X 10.2] d738f90084/bsd/kern/sys_generic.c (L220)
Related PR: rust-lang/rust#38622.
Experiment: Reborrow trait
Tracking issue: rust-lang/rust#145612
Starting off really small here: just introduce the unstable feature and the feature gate, and one of the two traits that the Reborrow experiment deals with.
### Cliff-notes explanation
The `Reborrow` trait is conceptually a close cousin of `Copy` with the exception that it disables the source (`self`) for the lifetime of the target / result of the reborrow action. It can be viewed as a method of `fn reborrow(self: Self<'a>) -> Self<'a>` with the compiler adding tracking of the resulting `Self<'a>` (or any value derived from it that retains the `'a` lifetime) to keep the `self` disabled for reads and writes.
No method is planned to be surfaced to the user, however, as reborrowing cannot be seen in code (except for method calls [`a.foo()` reborrows `a`] and explicit reborrows [`&*a`]) and thus triggering user-code in it could be viewed as "spooky action at a distance". Furthermore, the added compiler tracking cannot be seen on the method itself, violating the Golden Rule. Note that the userland "reborrow" method is not True Reborrowing, but rather a form of a "Fancy Deref":
```rust
fn reborrow(&'short self: Self<'long>) -> Self<'short>;
```
The lifetime shortening is the issue here: a reborrowed `Self` or any value derived from it is bound to the method that called `reborrow`, since `&'short` is effectively a local variable. True Reborrowing does not shorten the lifetime of the result.
To avoid having to introduce new kinds of references, new kinds of lifetime annotations, or a blessed trait method, no method will be introduced at all. Instead, the `Reborrow` trait is intended to be a derived trait that effectively reborrows each field individually; `Copy` fields end up just copying, while fields that themselves `Reborrow` get disabled in the source, usually leading to the source itself being disabled (some differences may appear with structs that contain multiple reborrowable fields). The goal of the experiment is to determine how the actual implementation here will shape out, and what the "bottom case" for the recursive / deriving `Reborrow` is.
`Reborrow` has a friend trait, `CoerceShared`, which is equivalent to a `&'a mut T -> &'a T` conversion. This is needed as a different trait and different operation due to the different semantics it enforces on the source: a `CoerceShared` operation only disables the source for writes / exclusive access for the lifetime of the result. That trait is not yet introduced in this PR, though there is no particular reason why it could not be introduced.
Fix overly restrictive lifetime in `core::panic::Location::file` return type
Fixes#131770 by relaxing the lifetime to match what's stored in the struct. See that issue for more details and discussion.
Since this is a breaking change, I think a crater run is in order. Since this change should only have an effect at compile-time, I think just a check run is sufficient.
Fixes an issue where if the underlying `Once` panics because it is
poisoned, the panic displays the wrong message.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
* 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
Consolidate panicking functions in `slice/index.rs`
Consolidate all the panicking functions in `slice/index.rs` to use a single `slice_index_fail` function, similar to how it is done in `str/traits.rs`.
Split off from https://github.com/rust-lang/rust/pull/145024
stdlib: Replace typedef -> type alias in doc comment
'typedef' is jargon from C and C++.
Since the Rust reference uses the term [type alias](https://doc.rust-lang.org/reference/items/type-aliases.html),
this patch changes the doc comment in io/error.rs
to also use 'type alias'.
std_detect: RISC-V: implement implication to "C"
Just like we implemented relatively complex rules to imply other extensions **from** "C" (and some others), this commit implements implication **to** the "C" extension from others, complying the following text in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations (*not* in this implementation) can (currently) imply the "C" extension.
Note: this is a `std_detect` change and not main target feature handling.
