Rollup of 16 pull requests - #162767
Merged
Merged
Rollup of 16 pull requests#162767
Conversation
The `require-explicit-cpu.json` case currently prints a "default target CPU" line; test for this. (It will change in the next commit.)
Specifically, don't print it when `need_explicit_cpu` is set, because it doesn't really make sense in that context. Right now among builtin targets this only affects the `amdgcn-amd-amdhsa` target, but it will also be relevant for the `avr2` target in the next commit. It also affects the `require-explicit-cpu.json` case in `tests/run-make/target-specs/rmake.rs`.
Currently rustc uses LLVM's `TargetMachine::getMCSubtargetInfo` method to access an `MCSubtargetInfo` to do feature testing. The next commit will change the feature testing to instead use an alternative pathway, LLVM's `Target::createMCSubtargetInfo` method. The two pathways have some slight differences. One difference relates to the `avr-none` target. Currently its `cpu` field isn't set so it gets the default "generic" value, which is not a valid AVR CPU name. This was hidden by the fact that the current LLVM pathway goes through the `getCPU` function in `AVRTargetMachine.cpp`, which rewrites "generic" as "avr2". But the alternative LLVM pathway doesn't rewrite "generic". Without an adjustment, we would get some behavioural differences with the alternative pathway, such as "unrecognized processor" errors and empty base feature sets. Therefore, this commit sets `cpu` to "avr2", a more obviously correct choice, and what the current LLVM pathway is effectively doing behind the scenes. You might think this would change the code generated by default, but `avr-none` has `need_explicit_cpu` set to true, so that's not the case, because a missing `-Ctarget-cpu` will trigger a fatal error before codegen. But `cpu` can still reach non-codegen paths (e.g. feature/cfg computation in session setup, and `--print`) so we need a valid backend name. A consequence of this is that `--print target-spec-json` will emit `cpu: "avr2"`. Another consequence is that the `requires_consistent_cpu` check will compare a crate built without `-Ctarget-cpu` (non-codegen only) against "avr2" instead of "generic". The commit also modifies two tests. In both cases, the test passes in this commit with or without the explicit `cpu` field. But in the next commit (using the alternative pathway) both tests would fail without the explicit `cpu` field: - `tests/ui/abi/avr-sram.rs` would fail with ``` 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) warning: target feature `sram` must be enabled to ensure that the ABI of the current target can be implemented correctly ``` - `tests/run-make/print-cfg/rmake.rs` would fail because all features would be missing. Finally, the field docs for `TargetOptions` are tweaked to clarify the interplay between `cpu` and `need_explicit_cpu`.
The `repr(transparent)` isn't necessary: there are no casts or transmutes involving it, and it's not passed by value across an FFI boundary. The `PhantomData` also isn't necessary: the type isn't generic so variance isn't a factor; the `Drop` impl doesn't involve `may_dangle`; and the `NonNull` field means the type is `!Send`/`!Sync` with or without the `PhantomData`.
`llvm::target_config` creates `target_machine` by calling `create_informational_target_machine`, which calls `target_machine_factory`, which uses `internal_target_features`. But this is just before `internal_target_features` is initialized! So we should move `internal_target_features` initialization before `target_machine`, right? But `internal_target_features` initialization involves a closure that inspects `target_machine`. There is a cyclic dependency. There is enough function nesting here that it's hard to spot. In practice this cycle doesn't cause problems because the closure doesn't inspect the parts of `target_machine` that depend on `internal_target_features`. But it demonstrates how startup initialization is all tangled up, and it's blocking some cleanups I am doing in rust-lang#161432 relating to the dangerous uses of `Session` before it's fully initialized. Therefore, this commit changes the first part: instead of creating an `OwnedTargetMachine` we create an `OwnedMCSubtargetInfo`. This is a smaller type that has the feature information we need but doesn't depend on `internal_target_features`. Under the covers we are now using LLVM's `Target::createMCSubtargetInfo` instead of `TargetMachine::getMCSubtargetInfo` so that we avoid having to create a `TargetMachine` at this early stage. This eliminates the cycle. (`TargetMachine` can still be created later on, once we're past this fraught initialization.) There are some slight differences between these two approaches, and the preceding commits fixed up some issues there. Some details about this commit: - The new `OwnedMCSubtargetInfo` is similar to the existing `OwnedTargetMachine`. - `create_informational_target_machine` no longer needs a `for_cfg` parameter, because the one site where `for_cfg` was true has been removed. - `LLVMRustCreateMCSubtargetInfo` mostly replicates part of `LLVMRustCreateTargetMachine` - `LLVMRustMCSubtargetInfoHasFeature` partly replicates `LLVMRustHasFeature`. - `LLVMRustHasFeature` is no longer needed. - The error message for `custom-target-invalid-llvm-target.rs` changed.
The panic was fixed in 7fbbd2039c30fa944ec534d6f54569015b36e939, but it didn't have a test. Add a test as suggested by @A4-Tacks, based on a minimised repro I'd seen (this panic was the most common I'd seen on the latest rust-analyzer version). AI disclosure: Test code with some help by Claude Opus 5, commit message by me.
…-regression-test internal: Add regression test for 'failed to unify type errors' panic
Accidentally removed during rust-lang/rust-analyzer@492420d
Mostly thanks to FPs having gotten fixed
By not giving anon consts their own owner. This eases work and does not cause harm. I had to revert making `TypeOwnerId` lifetime'd unfortunately but it was not hard (so it won't be hard to put it back when needed).
minor: Remove some unused code
…ne_of]` When invoking the "Add missing impl members" assist.
Because it's hugely annoying.
…flow-fork minor: Do not run the "Generate lints and feature flags" CI workflow on forks
ide: fix doc comment offset calculation
We tracked the depth perfectly but didn't do anything with it. Also fix the depth tracking for expression stores (it didn't intern the new ID with an incremented depth).
..and explain the reasoning using `reason`. Sometimes `expect` wouldn't work (for _reasons_), so keep `allow` in those cases. `lsp-extensions.md` didn't need updating, as the changes in `lsp/ext.rs` only touch the `allow` attribute.
Thus getting rid of the `allow`s
- `proc-macro-api` already had a dependency on `rustc_hash`, so moving
to it in `bidirectional_protocol/msg.rs` is fine
- Note: switching to `FxHashMap` reduced the size of
`ExpandMacroResponse`, so `clippy::large_enum_variant` no longer
triggers, hence its removal.
- that required mirroring the changes to `proc-macro-srv`, and therefore
also adding the dependency to it, but it had been a transitive
dependency already anyway.
- adding the dependency to `lsp-server` is... fine
- `smol_str` only needed a hash map for a test, so adding `rustc_hash`
isn't justified
- `xtask` and `ungrammar` are dev tooling, so adding a dependency on
rustc_hash is not worth it
to show that we expect it to be unused
Support for const blocks in pattern positions was removed from rustc in rust-lang@a9442b4 Remove Pat::ConstBlock from hir-def so rust-analyzer is consistent with rustc lowering. This also fixes a panic on closure calls in const blocks. This occurred because we ended up running type inference twice on ConstBlock in some code paths. AI disclosure: Code partly written by GPT-5.6, commit message and review by me.
Example
---
```rust
{"$": ""}
```
**Before this PR**
```text
panic: Failed to make ast node `syntax::ast::generated::nodes::Name` from text `mod $;`
```
**After this PR**
```text
💡 weak: JSON syntax is not valid as a Rust item
```
rustbot
added
T-libs
Member
Author
|
@bors r+ p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
Member
Author
|
Trying commonly failed jobs, so we can weed out more failures if autojobs fail |
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 14, 2026
Rollup of 16 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-gnu-llvm-21-3 try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu
Contributor
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Sep 14, 2026
Open
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing ed77b7b (parent) -> a8a1e6f (this PR) Test differencesShow 1025 test diffsStage 0
Stage 1
Stage 2
Additionally, 974 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard a8a1e6fd9df2e094d6f09c0d57991508680acc1c --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (a8a1e6f): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.1%, secondary -1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 495.332s -> 495.556s (0.05%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: ed77b7b869 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
Collaborator
Running triage with 14 benchmarksTriage only executes the benchmarks on rollup members, that were changed significantly on the rollup.
#161903 5fa9d1d Fix initialization cycle in
|
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
0.3% | [0.2%, 0.3%] | 2 |
| Improvements ✅ (primary) |
-0.6% | [-0.9%, -0.2%] | 7 |
| Improvements ✅ (secondary) |
-0.4% | [-0.8%, -0.1%] | 27 |
| All ❌✅ (primary) | -0.6% | [-0.9%, -0.2%] | 7 |
Max RSS (memory usage)
Results (secondary -3.5%)
A less reliable metric. May be of interest, but not used to determine the overall result above.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
- | - | 0 |
| Improvements ✅ (primary) |
- | - | 0 |
| Improvements ✅ (secondary) |
-3.5% | [-4.0%, -2.7%] | 3 |
| All ❌✅ (primary) | - | - | 0 |
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#162735 65f6e76 Remove pointless A: Allocator bounds in boxed.rs
This perf run didn't have relevant results for the `instruction count` metric.
Instruction count
This perf run didn't have relevant results for this metric.
Max RSS (memory usage)
Results (primary -2.1%)
A less reliable metric. May be of interest, but not used to determine the overall result above.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
- | - | 0 |
| Improvements ✅ (primary) |
-2.1% | [-2.1%, -2.1%] | 1 |
| Improvements ✅ (secondary) |
- | - | 0 |
| All ❌✅ (primary) | -2.1% | [-2.1%, -2.1%] | 1 |
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#162634 0c6f4b2 Implement semantic analysis for named Fn trait params
Instruction count
Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
0.3% | [0.3%, 0.3%] | 1 |
| Improvements ✅ (primary) |
- | - | 0 |
| Improvements ✅ (secondary) |
-0.2% | [-0.2%, -0.2%] | 1 |
| All ❌✅ (primary) | - | - | 0 |
Max RSS (memory usage)
This perf run didn't have relevant results for this metric.
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#162736 9d4a444 clean up trivial region constraint filtering
Instruction count
Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
0.3% | [0.3%, 0.3%] | 1 |
| Improvements ✅ (primary) |
- | - | 0 |
| Improvements ✅ (secondary) |
- | - | 0 |
| All ❌✅ (primary) | - | - | 0 |
Max RSS (memory usage)
This perf run didn't have relevant results for this metric.
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
rust-analyzersubtree update #162752 (rust-analyzersubtree update)target_config#161903 (Fix initialization cycle intarget_config)Fntrait params #162634 (Implement semantic analysis for namedFntrait params)unsafe_cell_access#162504 (Stabilizeunsafe_cell_access)>as a closing bracket #162516 (tidy: Sort multi-line types by treating>as a closing bracket)GinDiag<'a, G>#162630 (Simplify theGinDiag<'a, G>)A: Allocatorbounds in boxed.rs #162735 (Remove pointlessA: Allocatorbounds in boxed.rs)r? @ghost
Create a similar rollup