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
