Repository navigation
Rollup of 10 pull requests - #164050
Closed
JonathanBrouwer wants to merge 24 commits into
Closed
Rollup of 10 pull requests#164050JonathanBrouwer wants to merge 24 commits into
JonathanBrouwer wants to merge 24 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
…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 😅
…illaumeGomez
Pass the unremapped path to the `rustc` invocation for doctests
Turns out that `--remap-path-scope` is only half working with doctests, this is because `rustdoc` use a secret environment variable to pass the real filename of the doctest.
However we were only passing a remapped path. That means that doctests source path were getting remapped, but only for one scope: `documentation`. It didn't respect `macro` for `file!` for example.
To fix this, we have to:
1. pass the local path to the `rustc` invocation
2. have `rustc` treat that path as a real filename and apply remapping per scope to it
- I had to add a new `Input` variant, otherwise I can't differentiate normal input `-` from doctests `-` source
4. we have to pass `--remap-path-{prefix,scope}` to `rustc` so the path actually gets remap properly
…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-testsuite
rustbot
added
the
WG-trait-system-refactor
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
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
Contributor
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
11 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:
rustcinvocation for doctests #163956 (Pass the unremapped path to therustcinvocation for doctests)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