Repository navigation
Rollup of 10 pull requests - #164048
Closed
JonathanBrouwer wants to merge 23 commits into
Closed
Rollup of 10 pull requests#164048JonathanBrouwer wants to merge 23 commits into
JonathanBrouwer wants to merge 23 commits into
Conversation
…dates who have a failed `Normalization` nested goal. The previous condition on `ImplWhereBound` and co is now removed as it is unessecary. + add test of issue
Suggest only Span without source changes when source code is unavailable UI tests hide std library sources so diagnostics match what users may see when std sources are unavailable. In those cases, suggestions whose spans point into std macros cannot be rendered as source patches. Before this change, if all substitutions for a suggestion were filtered out because the source could not be loaded, the suggestion was dropped entirely. This meant useful help messages could disappear in UI test output, while it will appear in user's terminal. This adds a `-Zshow-suggestions-with-unavailable-source` flag and enables it for UI tests. When the annotate-snippet emitter cannot render a suggestion as a patch, but the original suggestion points to unavailable source, it now emits a span-only help instead: ```text help: consider using `drop` function --> $SRC_DIR/core/src/macros/mod.rs:LL:COL ``` cc rust-lang#139316 (comment)
…ckh726 Support type-relative assoc item paths in generic param defaults & const param types Background info: For resolving type-relative associated item paths, we only support a tiny set of self types (cc rust-lang#22519). If it's a non-`Self` type parameter we'll look through the "type param bounds" of the overarching item. *However*, in the case of generic parameter defaults and const parameter types this overarching "item" was set to the generic parameter. This meant that in these places we didn't look at the list of bounds of the overarching item when trying to resolve such type-relative associated item paths but at the one of the generic parameter which is always empty[^1] and thus failed unconditionally. Fixes rust-lang#87682. For the types FCP: This PR makes us accept the following code (stably): ```rs trait Trait { type Type; } struct Owner<T: Trait, U = T::Type>(T, U); // ~~~~~~~ now successfully resolves to <T as Trait>::Type ``` As alluded to, this PR also affects the resolution in const param defaults+types (intentionally, of course). However, I don't think this can be observed without the use of unstable features (like `min_generic_const_args` and `generic_const_parameter_types`). Nonetheless if you're interested in that, too, please check out the added UI tests. To the best of my knowledge this change *doesn't* make us reject more code (via new ambiguities or query cycles for example). <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub> [^1]: Generic params obviously never have generic params or bounds (à la (pseudo) `struct S<T<X: Trait> = X::Type>`) in the current version of Rust.
…ons, r=jackh726 Helpful suggestions for incorrect address-of mutability (2) Added suggestions for & and &raw expressions used as function arguments when the function expects a mutable address. There is now also a suggestion for providing a &raw const/mut when a reference was expected, as well suggestions when & was used but the function expected *mut. I also did a small refactor, grouping all 'suggest mut' code into a single function called suggest_addr_mut, and removed suggest_ptr_null_mut. Its logic was moved into the new suggest_addr_mut. The test at tests\ui\span\coerce-suggestions.rs was updated to trigger all new diagnostics and blessed accordingly. Fixes: rust-lang#159490. This PR is mostly a clean-up of rust-lang#160897, with an extra diagnostics thrown in at the suggestion of chenyukang. r? petrochenkov
…writing, r=khyperia -Zassumptions-on-binders: rewrite alias outlives constraints more goodly r? @khyperia best reviewed commit by commit. there are two improvements here. First, we no longer rewrite alias outlives constraints if they're not in the current universe. Previously we did so and it resulted in rewriting alias outlives constraints to `false` because of there being no assumptions available (because we only know assumptions for the current universe). I think this was just a whoopsie from my original PR because the other places we compute candidates *do* check the universe first lol. Second I merged the two codepaths which compute candidates via replacing current-universe-placeholders with bound vars. One of them did this for the whole constraint, the other did this just for the alias and elaborated the outlived region in `Alias: 'a` into an OR of all the regions larger than `'a`. e.g. `OR(Alias: 'b, Alias: 'c)` given assumptions that `'a: 'b` and `'a: 'c` hold. Merging them together makes the code a lot nicer but also is a slight correctness improvement as we can now get more specific constraints back when rewriting alias outlives, which means we need less general assumptions to prove them :3 See added test in the commit. Though, after updating the `expect` in that test it still passed on main before this PR because of rust-lang/project-assumptions-on-binders#26
…rovements, r=khyperia Better debug impls for some assumptions on binders types r? @khyperia Debug output for abby stuff was really annoying to read :> All of the assumptions had a tonne of unreadable stuff about the region graph rather than a nice output. I'm not entirely sure what to do here. I just omit the information now which uh feels kinda dubious but also having *both* of the relations is *so* noisy especially with their current representation where its just a list of nodes and edges where it's super hard to read 😅 Also made `LeafRegionConstraint` not spit out a tonne of span information polluting the entire everything when looking at region constraints 😅
…omez Allow testing cg-gcc on any target Discussed in rust-lang#124172. r? GuillaumeGomez
…on-visitor, r=lcnr Do not retain `Normalization` goal errors in nested goals for `BestObligationVisitor:: non_trivial_candidates ` When getting the `non_trivial_candidates`, also consider candidates whose nested candidates have a `TypeRelating` failure as well, instead of only impl-where clauses. Should fix rust-lang#161882 related: [#t-types/call-for-participation > diagnostics proof tree visitor is too eager](https://rust-lang.zulipchat.com/#narrow/channel/618216-t-types.2Fcall-for-participation/topic/diagnostics.20proof.20tree.20visitor.20is.20too.20eager/with/622349291) r? @lcnr
…, r=khyperia Fix - const parameters rejected when identical This keeps a series of cheaper checks before doing a more heavyweight comparison. Used the example in the issue as the test case. r? @khyperia Fixes rust-lang#162897
const-eval: ICE when we hit a non-const fn We made this a "nice" error solely so we can test miri-unleashed better, but it was never meant to be an error that users can actually get -- just a second line of defense in case there is a bug in our const checking logic. This seems to [cause some confusion](rust-lang#161627 (comment)) so let's make it an ICE when Miri is not unleashed. This also uncovered that even if `const_precise_live_drops` finds a problem, we still run the code that was found to not be const-safe: rust-lang#163973. r? @oli-obk Cc @tmiasko
properly ignore the current goal's usages Found this while working on rust-lang/trait-system-refactor-initiative#278. `HeadUsages` is `Copy`, so `.unwrap().ignore_usages()` mutates the copy instead of `entry`'s field 😄 On `many-where-clauses-with-aliases-hang.rs`, I had about a 2x wall time improvement, but only with `-Zdisable-param-env-normalization-hack`. I'm not sure if the difference is observable with just plain `-Znext-solver`. r? lcnr
rustbot
added
A-compiletest
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 9, 2026
Rollup of 10 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux 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 try-job: test-x86_64-gnu-llvm-22-3
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #144585, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 423f8c4 failed: CI. Failed job:
|
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
12 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:
Normalizationgoal errors in nested goals forBestObligationVisitor:: non_trivial_candidates#162443 (Do not retainNormalizationgoal errors in nested goals forBestObligationVisitor:: non_trivial_candidates)r? @ghost
Create a similar rollup