- Some UEFI protocols such as TCP4, TCP6, UDP4, UDP6, etc are managed by
service binding protocol.
- A new instance of such protocols is created and destroyed using the
corresponding service binding protocol.
- This PR adds abstractions to make using such protocols simpler using
Rust Drop trait.
- The reason to add these abstractions in a seperate PR from TCP4
Protocol is to make review easier.
[EFI_SERVICE_BINDING_PROTCOL](https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-service-binding-protocol)
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Fix inaccurate `std::intrinsics::simd` documentation
This addresses two issues:
- the docs on comparison operators (`simd_gt` etc.) said they only work for floating-point vectors, but they work for integer vectors too.
- the docs on various functions that use a mask did not document that the mask must be a signed integer vector. Unsigned integer vectors would cause invalid behavior when the mask vector is widened (unsigned integers would use zero extension, producing incorrect results).
r? ``@workingjubilee``
Use correct error message casing for `io::const_error`s
Error messages are supposed to start with lowercase letters, but a lot of `io::const_error` messages did not. This fixes them to start with a lowercase letter.
I did consider adding a const check for this to the macro, but some of them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
Buffer::read_more() is supposed to refill the buffer without discarding
its contents, which are in the range `pos .. filled`.
It mistakenly borrows the range `pos ..`, fills that, and then
increments `filled` by the amount read. This overwrites the buffer's
existing contents and sets `filled` to a too-large value that either
exposes uninitialized bytes or walks off the end of the buffer entirely.
This patch makes it correctly fill only the unfilled portion of the
buffer, which should maintain all the type invariants and fix the test
failure introduced in commit b1196717fc.
This patch makes BufReader::peek()'s doctest call read_more() to refill
the buffer before the inner reader hits EOF. This exposes a bug in
read_more() that causes an out-of-bounds slice access and segfault.
The WTF-8 version of `OsString` tracks whether it is known to be valid
UTF-8 with its `is_known_utf8` field. Specialize `From<AsRef<OsStr>>` so
this can be set for UTF-8 string types.
When concatenating two WTF-8 strings, surrogate pairs at the boundaries
need to be joined. However, since UTF-8 strings cannot contain surrogate
halves, this check can be skipped when one string is UTF-8. Specialize
`OsString::push` to use a more efficient concatenation in this case.
Unfortunately, a specialization for `T: AsRef<str>` conflicts with
`T: AsRef<OsStr>`, so stamp out string types with a macro.
Error messages are supposed to start with lowercase letters, but a lot
of `io::const_error` messages did not. This fixes them to start with a
lowercase letter.
I did consider adding a const check for this to the macro, but some of
them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
Fix Windows `Command` search path bug
Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,
```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();
// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```
This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).
This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.
r? libs-api
import `simd_` intrinsics
In most cases, we can import the simd intrinsics rather than redeclare them. Apparently, most of these tests were written before `std::intrinsics::simd` existed.
There are a couple of exceptions where we can't yet import:
- the intrinsics are not declared as `const fn` in the standard library, causing issues in the `const-eval` tests
- the `simd_shuffle_generic` function is not exposed from `std::intrinsics`
- the `simd_fpow` and `simd_fpowi` functions are not exposed from `std::intrinsics` (removed in https://github.com/rust-lang/rust/pull/137595)
- some tests use `no_core`, and therefore cannot use `std::intrinsics`
r? ```@RalfJung```
cc ```@workingjubilee``` do you have context on why some intrinsics are not exposed?
Update some comparison codegen tests now that they pass in LLVM20
Fixes#106107
Needed one tweak to the default `PartialOrd::le` to get the test to pass. Everything but the derived 2-field `le` test passes even without the change to the defaults in the trait.
When both width and precision flags are specified, then the character
width is counted twice. Instead, record the character width when
truncating it to the precision, so it does not need to be recomputed.
Simplify control flow so the cases are more clear.
Return unexpected termination error instead of panicing in `Thread::join`
There is a time window during which the OS can terminate a thread before stdlib can retreive its `Packet`. Currently the `Thread::join` panics with no message in such an event, which makes debugging difficult; fixes#124466.
Add UTF-8 validation fast paths in `Wtf8Buf`
This adds two more fast paths for UTF-8 validation in `Wtf8Buf`, making use of the `is_known_utf8` flag added in https://github.com/rust-lang/rust/pull/96869 (Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8).
r? `@ChrisDenton`
There is a subtlety which "other conditions must be upheld by the caller"
does not capture: `GlobalAlloc`/`alloc::dealloc()` require that the
provided layout will be *equal*, not just that it "fits", the layout
used to allocate. This is always true here due to how `allocate()`,
`grow()`, and `shrink()` are implemented (they never return a larger
allocation than requested), but that is a non-local property of the
implementation, so it should be documented explicitly.
Rollup of 8 pull requests
Successful merges:
- #137370 (adjust_abi: make fallback logic for ABIs a bit easier to read)
- #137444 (Improve behavior of `IF_LET_RESCOPE` around temporaries and place expressions)
- #137464 (Fix invalid suggestion from type error for derive macro)
- #137539 ( Add rustdoc-gui regression test for #137082 )
- #137576 (Don't doc-comment BTreeMap<K, SetValZST, A>)
- #137595 (remove `simd_fpow` and `simd_fpowi`)
- #137600 (type_ir: remove redundant part of comment)
- #137602 (feature: fix typo in attribute description)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't doc-comment BTreeMap<K, SetValZST, A>
This otherwise shows up in documentation as an empty impl block (worse, at the *top* of the docs above the public impls).
remove `#[rustc_intrinsic_must_be_overridde]`
In https://github.com/rust-lang/rust/pull/135031, we gained support for just leaving away the body. Now that the bootstrap compiler got bumped, stop using the old style and remove support for it.
r? `@oli-obk`
There are a few more mentions of this attribute in RA code that I didn't touch; Cc `@rust-lang/rust-analyzer`
remove some unnecessary rustc_const_unstable
If the function is anyway unstable, it doesn't need to be `rustc_const_unstable`.
`copy_from_slice` turns out to not do anything const-unstable itself, we just haven't stably committed to it being available in const yet. See [here](https://rustc-dev-guide.rust-lang.org/stability.html?highlight=rustc_const_stable_indirect) for more details on the `rustc_const_stable_indirect` attribute.
Implement `read_buf` for zkVM stdin
For the zkVM, even when a guest buffer is uninitialized, from the host's perspective it is just a normal piece of memory which was initialized before letting the guest write into it. This makes `sys_read` safe to use with an uninitialized buffer. See https://github.com/risc0/risc0/issues/2853.
cc `@bobbobbio,` `@flaub`
r? `@Noratrieb`
Tracked in https://github.com/rust-lang/rust/issues/136756
Update `String::from_raw_parts` safety requirements
These have become out of sync with `Vec::from_raw_part`'s safety requirements, and are likely to diverge again. I think it's safest to just point at `Vec`'s requirements.
https://github.com/rust-lang/rust/issues/119206#issuecomment-2180116680
Windows: use existing wrappers in `File::open_native`
Just a small improvement I've noticed - prevents accidents regarding `SetFileInformationByHandle` parameters.
Probably ``@ChrisDenton`` since we talked about it on discord :)
Unstable `gen_future` Feature Tracking
This PR removes the reference to the closed tracking issue **#50547** for the `gen_future` feature. Since `gen_future` is an internal feature used in async block desugaring, it does not require a public tracking issue.
#### Changes:
- Replaced `issue = "50547"` with `issue = "none"` in **library/core/src/future/mod.rs**.
- Ensures that it is correctly identified as an internal feature.
#### Rationale:
With this change, the Unstable Book will now state:
> *"This feature has no tracking issue and is therefore likely internal to the compiler, not being intended for general use."*
Closes **#76249**. 🚀🦀
Fixed issue with usage of generics and moved feature gate to crate root
Removed const tag
Fixed alphabetical ordering of feature gate, added same to doctest
Removed crate-level declaration of feature gate control_flow_into_value
Used const_precise_live_drops to constify into_value without issue of a drop
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
There is a time window during which the OS can terminate a thread before stdlib
can retreive its `Packet`. Currently the `Thread::join` panics with no message
in such an event, which makes debugging difficult; fixes#124466.
More const {} init in thread_local
`const {}` in `thread_local!` gets an optimization just based on the syntax, rather than the expression being const-compatible. This is easy to miss, so I've added more examples to the docs.
I've also added `const {}` in a couple of places in std where this optimization has been missed.
Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix
As discussion in #136737.
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `sockaddr_storage` in `accept()` and `recvfrom()` since these functions fill in the address structure
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `pthread_attr_t` in thread-related functions since `pthread_attr_init()` initializes the structure
- Add references to man pages to document this behavior
illumos has `posix_spawn`, and the very newest versions also have `_addchdir`,
so use that.
This is a nice ~4x performance improvement for process creation. My go-to as
usual is nextest against the clap repo, which acts as a stress test for process
creation -- with [this commit]:
```console
$ cargo nextest run -E 'not test(ui_tests) and not test(example_tests)'
before: Summary [ 1.747s] 879 tests run: 879 passed, 2 skipped
after: Summary [ 0.445s] 879 tests run: 879 passed, 2 skipped
```
[this commit]: fde45f9aea
Inject `compiler_builtins` during postprocessing and ensure it is made private
Follow up of https://github.com/rust-lang/rust/pull/135278
Do the following:
* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in #135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this
There is more detail in the commit messages. This includes the changes I was working on in https://github.com/rust-lang/rust/pull/136226.
try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7
Would otherwise fail there. The Windows7-specific parts were left pretty much untouched by the changes introduced by
51df98ddb0, so it is expected that these tests fail under Windows 7 as they were probably written to run under Windows 10+ only.
Add #[track_caller] to Duration Div impl
Previously the location of the divide-by-zero error condition would be attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
Would otherwise fail there. The Windows7-specific parts were left pretty
much untouched by the changes introduced by
51df98ddb0, so it is expected that these
tests fail under Windows 7 as they were probably written to run under
Windows 10+ only.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
libcore/net: `IpAddr::as_octets()`
[ACP](https://github.com/rust-lang/libs-team/issues/535)
[Tracking issue](https://github.com/rust-lang/rust/issues/137259)
Adds `const` `core::net::IpAddr{,v4,v6}::as_octets()` methods to provide reference access to IP address contents.
The concrete usecase for me is allowing the `IpAddr` to provide an extended lifetime in contexts that want a `&[u8]`:
```rust
trait AddrSlice {
fn addr_slice(&self) -> &[u8];
}
impl AddrSlice for IpAddrV4 {
fn addr_slice(&self) -> &[u8] {
// self.octets() doesn't help us here, because we can't return a reference to the owned array.
// Instead we want the IpAddrV4 to continue owning the memory:
self.as_octets()
}
}
```
(Notably, in this case we can't parameterize `AddrSlice` by a `const N: usize` (such that `fn addr_slice(&self) -> [u8; N]`) and maintain object-safety.)
Optionally add type names to `TypeId`s.
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.
It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)
Example usage and output:
```
fn main() {
use std::any::{Any, TypeId};
dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```
```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```
Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
Related issues:
* #68379
* #61533
The recent fixes to private dependencies exposed some cases in the UEFI
module where private dependencies are exposed in a public interface.
These do not need to be crate-public, so change them to `pub(crate)`.
In [1], most dependencies of `std` and other sysroot crates were marked
private, but this did not happen for `alloc` and `test`. Update these
here, marking public standard library crates as the only non-private
dependencies.
[1]: https://github.com/rust-lang/rust/pull/111076
Reduce `Box::default` stack copies in debug mode
The `Box::new(T::default())` implementation of `Box::default` only
had two stack copies in debug mode, compared to the current version,
which has four. By avoiding creating any `MaybeUninit<T>`'s and just writing
`T` directly to the `Box` pointer, the stack usage in debug mode remains
the same as the old version.
Another option would be to mark `Box::write` as `#[inline(always)]`,
and change it's implementation to to avoid calling `MaybeUninit::write`
(which creates a `MaybeUninit<T>` on the stack) and to use `ptr::write` instead.
Fixes: #136043
For the zkVM, even when a guest buffer is uninitialized, from the host's
perspective it is just a normal piece of memory which was initialized
before letting the guest write into it. This makes `sys_read` safe to
use with an uninitialized buffer. See
https://github.com/risc0/risc0/issues/2853.
Stabilize `num_midpoint_signed` feature
This PR proposes that we stabilize the signed variants of [`iN::midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201), the operation is equivalent to doing `(a + b) / 2` in a sufficiently large number.
The stabilized API surface would be:
```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a
/// sufficiently-large signed integer type. This implies that the result is
/// always rounded towards zero and that no overflow will ever occur.
impl i{8,16,32,64,128,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
```
T-libs-api previously stabilized the unsigned (and float) variants in #131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint.
This stabilization proposal proposes that we round towards zero because:
- it makes the obvious `(a + b) / 2` in a sufficiently-large number always true
- using another rounding for the positive result would be inconsistent with the unsigned variants
- it makes `midpoint(-a, -b)` == `-midpoint(a, b)` always true
- it is consistent with `midpoint(a as f64, b as f64) as i64`
- it makes it possible to always suggest `midpoint` as a replacement for `(a + b) / 2` expressions *(which we may want to do as a future work given the 21.2k hits on [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%5C%28%5Ba-zA-Z_%5D*+%5C%2B+%5Ba-zA-Z_%5D*%5C%29+%5C%2F+2%2F&type=code&p=1))*
`@scottmcm` mentioned a drawback in https://github.com/rust-lang/rust/pull/132191#issuecomment-2439891200:
> I'm torn, because rounding towards zero makes it "wider" than other values, which `>> 1` avoids -- `(a + b) >> 1` has the nice behaviour that `midpoint(a, b) + 2 == midpoint(a + 2, b + 2)`.
>
> But I guess overall sticking with `(a + b) / 2` makes sense as well, and I do like the negation property 🤷
Which I think is outweigh by the advantages cited above.
Closes#110840
cc `@rust-lang/libs-api`
cc `@scottmcm`
r? `@dtolnay`
Implement accepted ACP for functions that isolate the most significant
set bit and least significant set bit on unsigned, signed, and NonZero
integers.
Add function `isolate_most_significant_one`
Add function `isolate_least_significant_one`
Add tests
Organize `OsString`/`OsStr` shims
Synchronize the `bytes.rs` and `wtf8.rs` shims for `OsString`/`OsStr` so they're easier to diff between each other. This is mostly ordering items the same between the two. I tried to minimize moves and went for the average locations between the files.
With them in the same order, it is clear that `FromInner<_>` is not implemented for `bytes::Buf` and `Clone::clone_from` is not implemented for `wtf8::Buf`, but they are for the other. Fix that.
I added #[inline] to all inherent methods of the `OsString`/`OsStr` shims, because it seemed that was already the rough pattern. `bytes.rs` has more inlining than `wtf8.rs`, so I added the corresponding ones to `wtf8.rs`. Then, the common missing ones have no discernible pattern to me. They're not divided by non-allocating/allocating. Perhaps the pattern is that UTF-8 validation isn't inlined? Since these types are merely the inner values in `OsStr`/`OsString`, I put inline on all methods and let those public types dictate inlining. I have not inspected codegen or run benchmarks.
Also, touch up some (private) documentation comments.
r? ``````@ChrisDenton``````
Lint `#[must_use]` attributes applied to methods in trait impls
The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This PR adds it to the unused `#[must_use]` lint, and cleans the extra attributes in portable-simd and Clippy.
Use more explicit and reliable ptr select in sort impls
Using `if ...` with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations.
This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
Impl TryFrom<Vec<u8>> for String
I think this is useful enough to have :)
As a general question, is there any policy around adding "missing" trait implementations? (like adding `AsRef<T> for T` for std types), I mostly stumble upon them when using a lot of "impl Trait in argument position" like (`foo: impl Into<String>`)
Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants
This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per #45795, gated behind the `char_max_len` feature.
The constants are currently applied in the `alloc`, `core` and `std` libraries.
Add a bullet point to `std::fs::copy`
I needed to copy a file but I got the following error:
```
Os { code: 2, kind: NotFound, message: "No such file or directory" }
```
After read the documentation, I though the error was generated by the `from` parameter, forgetting the `to` part. Anyway, I got the error because the parent folder of `to` didn't exist.
Even if the documentation explicitly saying `but is not limited to just these cases`, I would like to add this case because I spent 3 hours around it.
This PR just wants to put a mention about it.
Adds `const` `Ip*Addr::as_octets` methods providing reference access to
`Ip*Addr` octets contents.
See https://github.com/rust-lang/libs-team/issues/535 for accepted ACP
with a more detailed justification.
fix docs for inherent str constructors
related to #131114
when implementing inherent str constructors in #136517, i forgot to change the docs, so the code examples still imported the `std::str` module and used the constructor from there, instead of using "itself" (the inherent constructor).
Locking documentation updates
- Reword file lock documentation to clarify advisory vs mandatory. Remove the
word "advisory", and make it more explicit that the lock may be advisory or
mandatory depending on platform.
- Document that locking a file fails on Windows if the file is opened only for append
Remove `std::os::wasi::fs::FileExt::tell`
Following #137165 (Use `tell` for `<File as Seek>::stream_position`), `tell` is now directly exposed via `stream_position`, making `<File as FileExt>::tell` redundant. Remove it.
`std::os::wasi::fs::FileExt::tell` is currently unstable and tracked in https://github.com/rust-lang/rust/issues/71213.
``@rustbot`` ping wasi
tests: Also gate `f16::erfc()` doctest with `reliable_f16_math` cfg
In #136324 the doctest for `f16::erf()` was gated with `reliable_f16_math`. Add the same gate on `f16::erfc()` to avoid:
rust_out.71e2e529d20ea47d-cgu.0:\
(.text._ZN8rust_out4main43_doctest_main_library_std_src_f16_rs_1321_017h485f3ffe6bf2a981E+0x38): \
undefined reference to `__gnu_h2f_ieee'
on MIPS (and maybe other architectures).
r? tgross35
Make ub_check message clear that it's not an assert
I've seen a user assume that their unsound code was *safe*, because ub_check prevented the program from performing the unsafe operation.
This PR makes the panic message clearer that ub_check is a bug detector, not run-time safety protection.
Previously the location of the divide-by-zero error condition would be
attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
Following #137165 (Use `tell` for `<File as Seek>::stream_position`),
`tell` is now directly exposed via `stream_position`, making
`<File as FileExt>::tell` redundant. Remove it.
Use `tell` for `<File as Seek>::stream_position`
Some platforms have a more efficient way to get the current offset of the file than by seeking. For example, Wasi has `fd_tell` and SOLID has `SOLID_FS_Ftell`. Implement `<File as Seek>::stream_position()` in terms of those.
I do not use any APIs that were not already used in `std`. Although, the `libc` crate has [`ftell`](https://docs.rs/libc/latest/libc/fn.ftell.html), [`ftello`](https://docs.rs/libc/latest/libc/fn.ftello.html), and [`ftello64`](https://docs.rs/libc/latest/libc/fn.ftello64.html), I do not know platform coverage. It appears that Windows has no `tell`-like API.
I have checked that it builds on each relevant platform.
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
In 136324 the doctest for `f16::erf()` was gated with
`reliable_f16_math`. Add the same gate on `f16::erfc()` to
avoid:
rust_out.71e2e529d20ea47d-cgu.0:\
(.text._ZN8rust_out4main43_doctest_main_library_std_src_f16_rs_1321_017h485f3ffe6bf2a981E+0x38): \
undefined reference to `__gnu_h2f_ieee'
on MIPS (and maybe other architectures).
Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.
Fixes#136046
`feature(deref_patterns)` tracking issue: https://github.com/rust-lang/rust/issues/87121
`Cow<'_, T>` should only implement `DerefPure` if its `Deref` impl is pure, which requires `<T::Owned as Borrow<T>>::borrow` to be pure. This PR restricts `impl DerefPure for Cow<'_, T>` to `T: Sized + Clone`, `T = [U: Clone]`, and `T = str` (for all of whom `<T::Owned as Borrow<T>>::borrow` is implemented in the stdlib and is pure).
cc ``@Nadrieril``
------
An alternate approach would be to introduce a new `unsafe trait BorrowPure<T>` analogous to `DerefPure` that could be implemented for `T: Sized`, `&T`, `&mut T`, `String`, `Vec`, `Box`, `PathBuf`, `OsString`, etc. https://github.com/rust-lang/rust/compare/master...zachs18:borrow-pure-trait
Use `const_error!` when possible
Replace usages of `io::Error::new(io::ErrorKind::Variant, "constant string")` with `io::const_error!(io::ErrorKind::Variant, "constant string")` to avoid allocations when possible. Additionally, fix `&&str` error messages in SGX and missing/misplaced trailing commas in `const_error!`.
* Order items as the average of the two adaptors. Enables easier diffs.
* Consistently apply #[inline].
* Implement FromInner<Vec<u8>> for bytes::Buf.
* Implement Clone::clone_from for wtf8::Buf.
Apply unsafe_op_in_unsafe_fn to the standard library
This applies unsafe_op_in_unsafe_fn to the standard library in preparation for updating to Rust 2024.
Closes https://github.com/rust-lang/rust/issues/127747 (I think?) cc ``@workingjubilee``
I have been testing a variety of targets, and I feel like they are all pretty much covered. I'll continue doing some testing async, but I don't expect to catch any more.
Make Rust pointers less magic by including metadata information in their
`Debug` output.
This does not break Rust stability guarantees because `Debug` output is
explicitly exempted from stability:
https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability
Co-authored-by: Lukas <26522220+lukas-code@users.noreply.github.com>
Co-authored-by: Josh Stone <cuviper@gmail.com>
Because `.as_ptr()` changes the type of the pointer (e.g. `&[u8]`
becomes `*const u8` instead of `*const [u8]`), and it can't be expected
that different types will be formatted the same way.
Forward all default methods for I/O impls
Forward all default methods for `&mut T` and `Box<T>` to the inner `io::Read`, `io::Write`, `io::Seek`, and `io::BufRead` types.
Windows: Update generated bindings
Update to windows-bindgen 0.59.
This update is aimed at reducing churn in the future, but means a bit more churn now:
- `bindings.txt` no longer needs us to write the namespace for each item. This is good because it means in the future we won't need to change them if the namespace changes. However, there are a few where we still need to disambiguate due to duplicate items (this is a bug in the upstream metadata).
- The output in `windows-sys.rs` is now sorted. It was mostly sorted before but not intentionally. This should mean future changes are less noisy.
The actual code changes are minimal here. A few types are now `bool` instead of `BOOLEAN`, which is more convenient.
Implement Extend<AsciiChar> for String
Implement `Extend<AsciiChar>` for `String` as suggested in https://github.com/rust-lang/rust/issues/110998#issuecomment-2590122968. Also implements `Extend<&AsciiChar>` since there's an analogous impl for `Extend<&char>`, but happy to remove if not thought useful.
r? `@scottmcm`
since you requested it, but no pressure to review!
Prepare standard library for Rust 2024 migration
This includes a variety of commits preparing the standard library for migration to Rust 2024.
The actual migration is blocked on a few things, so I wanted to get this out of the way in a relatively digestable PR.
Stabilize `const_is_char_boundary` and `const_str_split_at`.
Tracking issues: #131516, #131518
Stabilized const API:
```rs
// in `core`
impl str {
// const_is_char_boundary feature
const fn is_char_boundary(&self, index: usize) -> bool;
// const_str_split_at feature, depends on const_is_char_boundary
const fn split_at(&self, mid: usize) -> (&str, &str);
const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str);
const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>;
const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>;
}
```
This will allow safely splitting string slices during const-eval.
Closes#131516, Closes#131518
This will need FCP.
r? libs-api
IIUC these do not use any new const language features (i.e. they are implementable manually on stable 1.83.0 using `unsafe`: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3679632cd1041084796241b7ac8edfbd)).
Cc ``@rust-lang/wg-const-eval`` (I don't know if I have the permissions for this ping; if not, someone else please ping wg-const-eval if it is necessary)
These functions were changed to be safe in
https://github.com/rust-lang/rust/pull/127763, but this particular UWP
version was missed. Otherwise this causes unnecessary unsafe block
warnings/errors.
alloc boxed: docs: use MaybeUninit::write instead of as_mut_ptr
In the deferred initialization pattern, the docs were needlessly going through `as_mut_ptr().write()` to initialize, which is unnecessary use of a pointer, needs to be inside an `unsafe` block, and may weaken alias analysis.
Remove the common prelude module
This fixes the issues described in https://github.com/rust-lang/rust/issues/136102. Primarily, this resolves some issues with how the documentation for the prelude is generated:
- It avoids showing "unstable" for macros in the prelude that are actually stable.
- Avoids duplication of some pages due to the previous lack of `doc(no_inline)`.
- Makes the different edition preludes consistent, and sets a pattern that can be used by future editions.
We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
Closes https://github.com/rust-lang/rust/issues/136102
`transmute` should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
[AIX] expect `EINVAL` for `pthread_mutex_destroy`
Calling `pthread_mutex_destory` on a mutex initalized with the static initializer macro `PTHREAD_MUTEX_INITIALIZER` will result in `EINVAL` if the mutex is not lock/unlocked prior to calling `pthread_mutex_destroy`.
This generates a warning of irrefutable patterns. I decided to slightly
tweak the example so the closure returns unit, since the intent wasn't
to show the weird behavior of returning `!`.
A small workaround for https://github.com/rust-lang/rust/issues/136899,
rustdoc's invalid_rust_codeblocks was not handling this well in 2024.
This may be needed when migrating to 2024 when building with stage0.
In the deferred initialization pattern, the docs were needlessly going
through as_mut_ptr().write() to initialize, which is unnecessary use of
a pointer, needs to be inside an unsafe block, and may weaken alias
analysis.
