Uh oh!
There was an error while loading. Please reload this page.
Rollup of 12 pull requests - #153741
Merged
Merged
Conversation
Addresses feedback from <rust-lang#147268 (comment)>
remove span_delayed_bug
There is a bunch of complexity supporting the "cannot check whether the hidden type of opaque type satisfies auto traits" error that shows up in `tests/ui/impl-trait/auto-trait-leak.rs`. This is an obscure error that shows up in a single test. If we are willing to downgrade that error message to a cycle error, we can do the following. - Simplify the `type_of_opaque` return value. - Remove the `cycle_stash` query modifier. - Remove the `CyclePlaceholder` type. - Remove the `SelectionError::OpaqueTypeAutoTraitLeakageUnknown` variant. - Remove a `FromCycleError` impl. - Remove `report_opaque_type_auto_trait_leakage`. - Remove the `StashKey::Cycle` variant. - Remove the `CycleErrorHandling::Stash` variant. That's a lot! I think this is a worthwhile trade-off.
This simplifies the inner function's signature, and makes it more consistent with other uses of `for_each_query_vtable!`.
When a delegation path like `reuse Trait::<> as bar4` has a child segment that resolves to a trait instead of a function, the compiler would ICE because `lower_generic_args_of_path` asserts that `self_ty` is `Some` when `has_self` is true and `parent` is `None`. Fix this by filtering out non-function child segments early using `.filter()` in the method chain, so that when the child segment resolves to a trait (error recovery for E0423), we skip generic args computation entirely and return an empty list via `unwrap_or_default()`. Also make `get_segment` return `Option` by using `opt_def_id()` instead of `def_id()` to gracefully handle unresolved segments.
…range_end_end, r=davidtwco Stop using rustc_layout_scalar_valid_range_* in rustc *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152569)* Another step towards rust-lang#135996 Required some manual impls, but we already do many manual impls for the newtype_index types, so it's not really a new maintenance burden.
…petrochenkov Fix ICE in fn_delegation when child segment resolves to a trait Fixesrust-lang#153420 When a delegation path like `reuse Trait::<> as bar4` has only one segment resolving to a trait (not a function), the child args processing in `get_delegation_user_specified_args` called `lower_generic_args_of_path` with `self_ty = None`. Since the trait's generics have `has_self = true`, this triggered `assert!(self_ty.is_some())`. Fix by computing and providing `self_ty` when the child segment's `def_id` has `has_self`. In valid delegation code the child segment always resolves to a function, so this only affects error recovery.
…mann Avoid ICE when an EII declaration conflicts with a constructor Fixesrust-lang#153502 When an `#[eii]` declaration conflicts with a tuple-struct constructor of the same name, error recovery can resolve the EII target to the constructor instead of the generated foreign item. `compare_eii_function_types` then assumes that target is a foreign function and later ICEs while building diagnostics. This pull request adds an early guard in `compare_eii_function_types` to skip EII signature comparison unless the resolved target is actually a foreign function.
Simplify `type_of_opaque`. There is a bunch of complexity supporting the "cannot check whether the hidden type of opaque type satisfies auto traits" error that shows up in `tests/ui/impl-trait/auto-trait-leak.rs`. This is an obscure error that shows up in a single test. If we are willing to downgrade that error message to a cycle error, we can do the following. - Simplify the `type_of_opaque` return value. - Remove the `cycle_stash` query modifier. - Remove the `CyclePlaceholder` type. - Remove the `SelectionError::OpaqueTypeAutoTraitLeakageUnknown` variant. - Remove a `FromCycleError` impl. - Remove `report_opaque_type_auto_trait_leakage`. - Remove the `StashKey::Cycle` variant. - Remove the `CycleErrorHandling::Stash` variant. That's a lot! I think this is a worthwhile trade-off. r? @oli-obk
…li-obk interpret: go back to regular string interpolation for error messages Using the translatable diagnostic infrastructure adds a whole lot of boilerplate which isn't actually useful for const-eval errors, so let's get rid of it. This effectively reverts rust-lang#111677. That PR effectively added 1000 lines and this PR only removes around 600 -- the difference is caused by (a) keeping some of the types around for validation, where we can use them to share error strings and to trigger the extra help for pointer byte shenanigans during CTFE, and (b) this not being a full revert of rust-lang#111677; I am not touching diagnostics outside the interpreter such as all the const-checking code which also got converted to fluent in the same PR. The last commit does something similar for `LayoutError`, which also helps deduplicate a bunch of error strings. I can make that into a separate PR if you prefer. r? @oli-obkFixesrust-lang#113117Fixesrust-lang#116764Fixesrust-lang#112618
…abels, r=estebank Unify same-span labels in move error diagnostics Fixesrust-lang#153506. When there's a single binding in a move error, we emit "data moved here" and "move occurs because ... does not implement the Copy trait" as two separate labels on the same span. This combines them into one label via a new `TypeNoCopy::LabelMovedHere` variant. The multi-binding case still uses separate labels + a note since they point at different spans. cc @estebank
…i865 mir-opt: Drop invalid debuginfos after SingleUseConsts. Fixesrust-lang#153601.
…cote Introduce `for_each_query_vtable!` to move more code out of query macros After rust-lang#153114 moved a few for-each-query functions into the big `rustc_query_impl::plumbing` macro, I have found that those functions became much harder to navigate and modify, because they no longer have access to ordinary IDE features in rust-analyzer. Even *finding* the functions is considerably harder, because a plain go-to-definition no longer works smoothly. This PR therefore tries to move as much of that code back out of the macro as possible, with the aid of a smaller `for_each_query_vtable!` helper macro. A typical use of that macro looks like this: ```rust for_each_query_vtable!(ALL, tcx, |query| { query_key_hash_verify(query, tcx); }); ``` The result is an outer function consisting almost entirely of plain Rust code, with all of the usual IDE affordances expected of normal Rust code. Because it uses plain Rust syntax, it can also be formatted automatically by rustfmt. Adding another layer of macro-defined macros is not something I propose lightly, but in this case I think the improvement is well worth it: - The outer functions can once again be defined as “normal” Rust functions, right next to their corresponding inner functions, making navigation and modification much easier. - The closure expression is ordinary Rust code that simply gets repeated ~300 times in the expansion, once for each query, in order to account for the variety of key/value/cache types used by different queries. Even within the closure expression, IDE features still *mostly* work, which is an improvement over the status quo. - For future maintainers looking at the call site, the macro's effect should hopefully be pretty obvious and intuitive, reducing the need to even look at the helper macro. And the helper macro itself is largely straightforward, with its biggest complication being that it necessarily uses the `$name` metavar from the outer macro. There should be no change to compiler behaviour. r? nnethercote (or compiler)
miri-test-libstd: use --tests and update some comments rust-lang#153143 added `./x test --tests` matching `cargo --tests`, which is exactly what Miri wants when testing the standard library. So let's use it for that. We can then also remove a hack in `library/alloctests/benches/vec_deque_append.rs`. Also update the comment for why the other benchmarks still need to be disabled in Miri, and remove some `cfg_attr` that seem unnecessary since the entire crate that contains them is already disabled in Miri. Those were copied over in rust-lang@b8fa843 -- they used to be needed since benches and tests were in the same crate, but they aren't any more.
…t, r=Kobzol Make Enzyme has dependent on LLVM hash This issue was encountered a few times by autodiff contributors. Closesrust-lang#152969 Just adding the llvm hash here triggered a rebuild of Enzyme locally, but I'll admit I didn't try it with a real llvm submodule update. r? @Kobzol
remove `.ftl` checks from tidy These files have been removed following rust-lang/compiler-team#959. Part of rust-lang#151366.
… r=RalfJung doc/rustc: clarify how to contact arm-maintainers Addresses feedback from rust-lang#147268 (comment)
JonathanBrouwer
commented
Mar 11, 2026
MemberAuthor
@bors r+ rollup=never p=5 |
Contributor
This comment has been minimized.
This comment has been minimized.
Contributor
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 3b1b0ef (parent) -> d1ee5e5 (this PR) Test differencesShow 189 test diffsStage 1
Stage 2
Additionally, 182 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 d1ee5e59a964a419b84b760812a35075034f4861 --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 |
This was referenced Mar 12, 2026
Merged
rust-timer
commented
Mar 12, 2026
Collaborator
Finished benchmarking commit (d1ee5e5): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur 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 2.2%, secondary 1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 491.073s -> 480.488s (-2.16%) |
Mark-Simulacrum
commented
Mar 16, 2026
Member
We don't seem to have unrolled builds. At a glance, cachegrind diff of diesel suggests the regression is in trait solving, though it's a bit hard to interpret. If so I'm suspecting #153581 as being the root cause. That cleanup is probably worth the small regression presuming it's the cause, so I'll go ahead and mark as triaged. |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
15 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:
type_of_opaque. #153581 (Simplifytype_of_opaque.)for_each_query_vtable!to move more code out of query macros #153685 (Introducefor_each_query_vtable!to move more code out of query macros).ftlchecks from tidy #153710 (remove.ftlchecks from tidy)r? @ghost
Create a similar rollup