compiler: update hashbrown to 0.17
See library's rust-lang/rust#155154 for the bug fixes this brings.
This PR also updates `indexmap` in the compiler as a direct dependent.
Remove dead diagnostic structs.
One of these has a "FIXME(autodiff): I should get used somewhere" comment, but I figure YAGNI applies and it's so small that reinstating it if necessary would be trivial.
r? @Kivooeo
remove PointeeParser
this parser does nothing currently, as the current scope of `rustc_attr_parsing` only includes builtin attributes, and not derive macros
it isn't defined in `compiler/rustc_feature/src/builtin_attrs.rs`
all the actual parsing for `#[pointee]` is actually handled in `compiler/rustc_builtin_macros/src/deriving/coerce_pointee.rs`
r? @JonathanBrouwer
Delete unused `rustc_trait_selection` errors.
The first two of these are duplicated elsewhere in some form or another, apparently they became orphaned during various moves and refactors. The third is just never used.
Tests for precise-capture through RPIT and TAIT
- Tests for https://github.com/rust-lang/rust/issues/155151.
These tests succeed under `-Znext-solver`, but incorrectly fail under the old trait solver.
---
The bug can be triggered via return-position `impl Trait` on stable, but requires some rather contrived code. When using type-alias `impl Trait`, it's easier to imagine the issue being triggered by real code.
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.
Fix ICE when Self is used in enum discriminant of a generic enum
Fixesrust-lang/rust#153756
Let discriminant AnonConst inherit parent generics via Node::Variant in generics_of, and emit a proper error instead of span_bug! for the TooGeneric case in wfcheck.
One of these has a "FIXME(autodiff): I should get used somewhere"
comment, but I figure YAGNI applies and it's so small that reinstating
it if necessary would be trivial.
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")
* Fix ICE when Self is used in enum discriminant of a generic enum
Move the validation into the existing `check_param_uses_if_mcg` machinery
in HIR ty lowering instead of adding a new check in wfcheck. After the
`AnonConstKind` refactoring, `ForbidMCGParamUsesFolder` was only gated on
`AnonConstKind::MCG`, causing discriminant anon consts (`NonTypeSystem`) to
bypass it entirely.
Add `anon_const_forbids_generic_params()` which returns the appropriate
`ForbidParamContext` for both MCG and enum discriminant contexts. Wire it
into `check_param_uses_if_mcg` so that `Self` aliasing a generic type is
caught before reaching `const_eval_poly`. Convert the `TooGeneric` span_bug
into a proper diagnostic as a fallback for anything slipping through
type-dependent path resolution.
* Address review comments
- Rename `ForbidMCGParamUsesFolder` to `ForbidParamUsesFolder`
- Rename `MinConstGenerics` variant to `ConstArgument` with updated doc
- Simplify doc comment on `anon_const_forbids_generic_params`
- Make match on `AnonConstKind` exhaustive
- Move `anon_const_def_id` inside the `if let` in `check_param_uses_if_mcg`
- Remove now-unreachable `TooGeneric` span_err in wfcheck
* Revert TooGeneric arm back to span_bug! as requested by reviewer
* Use generics_of to determine if NonTypeSystem anon consts allow generic params
* Also check InlineConst and Closure defs nested in enum discriminants
* Simplify logic for determining anonymous constant parent in generic contexts
* add test
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)
Balt