Rollup of 15 pull requests#154985
Conversation
On targets with convergent operations, we need to add the convergent attribute to all functions that run convergent operations. Following clang, we can conservatively apply the attribute to all functions when compiling for such a target and rely on LLVM optimizing away the attribute in cases where it is not necessary. This affects the amdgpu and nvptx targets.
start paragraph with upper case
- Specifically guide new contributors that unit tests for `core` and `alloc` do not belong within those crates and instead belong in the `coretests` and `alloctests` crates. - Also add some information about which `lib.rs` file needs the unstable feature declarations
Update information about adding unit tests
fix a sentence regarding early bounds
Fix `rustc_hir::Crate` links
Add explanation of default flags for UI tests
add chapter on projection vs trait split
Explain how nested generic args are represented
projection vs trait bound split cleanup
Fix rustc-pull CI workflow
inline with the rename in PR rust-lang#115764
Change `ConstValue::ByRef` to `ConstValue::Indirect`
…next-solver, r=TaKO8Ki Fix ICE in next-solver dyn-compatibility check The next solver treated error-containing dispatchability goals as proven and misclassified the trait as dyn compatible. Short-circuit receivers with type errors so object-method confirmation stays on the normal error path. Tracking issue: rust-lang#130516 Closes: rust-lang#151311
…r=Nadrieril Add getters for `rustc_pattern_analysis::constructor::Slice` fields rust-analyzer needs that. r? @Nadrieril
match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness
Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when the match contains arms without guards. Previously, this note was shown only if all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type.
Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern.
This will make a program like:
```rust
fn main() {
let some_condition = true;
let some_option: Option<u8> = None;
let _res = match some_option {
Some(val) if some_condition => val,
None => 0,
};
}
```
produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing.
Closes rust-lang#104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?
Use derived impl for `GappedRange` subdiagnostic
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@912f6c6. Created using https://github.com/rust-lang/josh-sync. r? @ghost
This comment has been minimized.
This comment has been minimized.
Rollup of 15 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
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 e26dedc (parent) -> c771f6e (this PR) Test differencesShow 255 test diffsStage 0
Stage 1
Stage 2
(and 11 additional test diffs) Additionally, 144 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 c771f6ee804969b5c046393c4110c22720e56114 --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 |
|
📌 Perf builds for each rolled up PR:
previous master: e26dedca9d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (c771f6e): comparison URL. Overall result: ✅ improvements - no action needed@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 (secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.9%)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: 488.355s -> 490.389s (0.42%) |
Successful merges:
pattern_tyinTestableCase#154879 (Don't storepattern_tyinTestableCase)unreachable_codelint inderive(PartialEq, Clone)#154910 (Suppressunreachable_codelint inderive(PartialEq, Clone))rustc_pattern_analysis::constructor::Slicefields #154934 (Add getters forrustc_pattern_analysis::constructor::Slicefields)GappedRangesubdiagnostic #154961 (Use derived impl forGappedRangesubdiagnostic)r? @ghost
Create a similar rollup