Test/lexer unicode pattern white space
This PR adds a test for the Rust lexer to verify it correctly accepts vertical tab (`\x0B`) as valid whitespace between tokens. Vertical tab is part of Unicode Pattern_White_Space, which the Rust language specification uses to define whitespace.
Related: Outreachy tracking [Pattern_White_Space](https://www.unicode.org/reports/tr31/#R3a)
Clarify ascii whitespace exclusion of vertical tab in the doc
This especially means that for `c: char`, `c.is_ascii() && c.is_whitespace()` does **not** imply `c.is_ascii_whitespace()`, which can cause bug and is highly counterintuitive.
docs: clarify path search behavior in std::process::Command::new
the existing docs mentioned that `PATH` is searched in an "os defined way" and that it could be controlled by setting PATH on the command but never explained which `PATH` is actually used.
on unix the key thing to understand is that when you modify the childs environment (via `env()`, `env_remove()`, or `env_clear()`), the `PATH` search uses whatever `PATH` ends up in the child's environment not the parents. so if you call `env_clear()` and forget to set `PATH`, you don't get the parents `PATH` as a fallback; you get the OS default (typically `/bin:/usr/bin`) which often won't find what you need.
the three cases are now documented:
- unmodified env: child inherits parents `PATH`, that gets searched
- `PATH` explicitly set `via env()`: the new value is searched
- `PATH` removed (`env_clear` or `env_remove`): falls back to OS default, not the parents `PATH`
on windows rust resolves the executable before spawning rather than letting `CreateProcessW` do it. the search order is: childs `PATH` (if explicitly set) first then system-defined directories then the parents `PATH`. the existing note about issue rust-lang/rust#37519 is preserved.
limitations in this doc:
- the unix fallback path behavior ("typically `/bin:/usr/bin`") is verified for linux/glibc. behavior on macOS, BSD, and musl is similar in practice but not fully confirmed here.
- the windows search order is summarized as "system-defined directories" which actually includes the application directory (the directory of the calling process's executable) as a distinct step before the system dirs that detail is omitted for brevity.
- `posix_spawnp` `PATH` source (calling process environ vs envp argument) is ambiguous in the `POSIX` spec; the behavior here is inferred from the guard in `unix.rs` that bypasses `posix_spawn` when `PATH` has been modified.
closesrust-lang/rust#137286 (hopefully)
`BorrowedBuf`: Update outdated safety comments in `set_init` users.
These comments appear to have been written before `BorrowedBuf`'s init tracking was simplified in
https://github.com/rust-lang/rust/pull/150129. The `BufWriter` comment of the usage within `BufWriter` will be handled separately.
CC rust-lang/rust#78485, rust-lang/rust#117693.
explicit-tail-calls: disable two tests on LoongArch
A [recent LLVM change](https://github.com/llvm/llvm-project/pull/191508) broke these on LLVM 23.
I suspect these will eventually be fixed, so maybe it'd be okay/better to just leave this pending so it applies to our CI without merging it? I'm open to opinions.
These comments appear to have been written before `BorrowedBuf`'s
init tracking was simplified in
https://github.com/rust-lang/rust/pull/150129. The `BufWriter` comment
of the usage within `BufWriter` will be handled separately.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#154049 (delegation: Track more precise spans for glob delegations)
- rust-lang/rust#155134 (Replace custom trim_ascii_start with the standard library method)
- rust-lang/rust#155235 (add the `fma4` x86 target feature)
- rust-lang/rust#155218 (coroutines: Skip the closure signature annotation check for tainted bodies)
- rust-lang/rust#155274 (limit duplicate-profiler-builtins test to targets that can do dynamic linking)
- rust-lang/rust#155276 (`#[rustc_must_match_exhaustively]` detect let else)
- rust-lang/rust#155281 (Revert "allow `windows-gnu` targets to embed gdb visualizer scripts")
limit duplicate-profiler-builtins test to targets that can do dynamic linking
this is the error I got for an example of such a target
```
=== STDERR ===
error: extern location for dylib_a does not exist: libdylib_a.so
--> main.rs:2:5
|
2 | dylib_a::something();
| ^^^^^^^
error: extern location for dylib_b does not exist: libdylib_b.so
--> main.rs:3:5
|
3 | dylib_b::something_else();
| ^^^^^^^
coroutines: Skip the closure signature annotation check for tainted bodies
When a coroutine has too many parameters, `check_match` fails and `construct_error` builds a MIR body with only the coroutine's computed arguments (env + resume type). The user-provided signature, however, still reflects all the parameters the user wrote. `check_signature_annotation` then tries to `zip_eq` these two mismatched iterators, causing a panic. Checking `tainted_by_errors` and bailing early avoids this, since `construct_error` bodies cannot meaningfully be compared against user annotations.
Example currently ICEing:
```rust
fn main() {
|(1, 42), ()| yield;
}
```
Closesrust-lang/rust#139570.
Replace custom trim_ascii_start with the standard library method
The markdown parser in `rustc_errors` has a local `trim_ascii_start` function that strips leading ASCII whitespace from a byte slice. The standard library has had `<[u8]>::trim_ascii_start()` since Rust 1.80, which does the same thing.
This PR removes the custom function and calls the stdlib method directly in `parse_unordered_li` and `parse_ordered_li`. No behaviour change.
I also added a test covering the list item leading-whitespace trimming behaviour, including a tab case.
Fixesrustfoundation/interop-initiative#53
delegation: Track more precise spans for glob delegations
The last commit also fixes a macro hygiene issue with `self` in delegations found in https://github.com/rust-lang/rust/pull/154002.
Post-attribute ports cleanup pt. 1 (again)
This is a re-implementation of most (but not all) of https://github.com/rust-lang/rust/pull/154808
The code is the same as in that PR, other than a few changes, I'll leave comments where I changed things.
I did re-implement most of the commits rather than cherry-picking, so it's probably good to check the entire diff regardless
r? @jdonszelmann
Instead of the last segment of the delegation path.
`self` is something that introduced by the whole delegation item, not some specific part of it, and the last segment may need to have a different context for path resolution purposes.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#152530 (Use the term struct-like variant instead of anonymous structs for data of struct-like enum variants)
- rust-lang/rust#155005 (preserve SIMD element type information)
- rust-lang/rust#155230 (Avoid linting `doc_cfg` as unused in rustc)
preserve SIMD element type information
Preserve the SIMD element type and provide it to LLVM for better optimization.
This is relevant for AArch64 types like `int16x4x2_t`, see also https://github.com/llvm/llvm-project/issues/181514. Such types are defined like so:
```rust
#[repr(simd)]
struct int16x4_t([i16; 4]);
#[repr(C)]
struct int16x4x2_t(pub int16x4_t, pub int16x4_t);
```
Previously this would be translated to the opaque `[2 x <8 x i8>]`, with this PR it is instead `[2 x <4 x i16>]`. That change is not relevant for the ABI, but using the correct type prevents bitcasts that can (indeed, do) confuse the LLVM pattern matcher.
This change will make it possible to implement the deinterleaving loads on AArch64 in a portable way (without neon-specific intrinsics), which means that e.g. Miri or the cranelift backend can run them without additional support.
discussion at [#t-compiler > loss of vector element type information](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/loss.20of.20vector.20element.20type.20information/with/584483611)
tidy: handle `#[cfg_attr(bootstrap, doc = "...")]` in `compiler/` comments
For the unbalanced backtick check that Waffle ran into in https://github.com/rust-lang/rust/pull/154887.
This PR cherry-picks Waffle's tidy patch in that PR (and adds some explaining comments) even though I'd say this is somewhat hacky[^1]. But since the original tidy check implementation is already based on heuristics and so are likewise fuzzy, this is probably fine in practice for most cases.
[^1]: There can be false positives/negatives like having both fragments `cfg_attr` and `doc` inside a string literal, but I would expect that to be very very niche, so it's "good enough".
(I wanted to write a regression test, but this check needs some restructuring to make it more easy to test that I don't want to bundle in this PR.)
r? wafflelapkin (or bootstrap/compiler)
Trait aliases: Also imply default trait bounds on type params other than `Self`
Trait aliases already correctly imply default trait bounds on `Self` type params. However, due to an oversight, they didn't do that for normal type params.
Fixesrust-lang/rust#152687.
Implement `-Z allow-partial-mitigations` (RFC 3855)
This implements `-Z allow-partial-mitigations` as an unstable option, currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo` rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).
r? @rcvalle
The local trim_ascii_start function in the markdown parser duplicates
<[u8]>::trim_ascii_start() from the standard library (stable since 1.80).
Remove the custom function and call the stdlib method directly.
No behaviour change.
Fixes https://github.com/rustfoundation/interop-initiative/issues/53
Start using pattern types in libcore
cc rust-lang/rust#135996
Replaces the innards of `NonNull` with `*const T is !null`.
This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.
Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types
Jacob Pratt