Don't build ParamEnv and do trait solving in ItemCtxts when lowering IATs
#140247
+542
−288
Conversation
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
rustbot
added
S-waiting-on-review
|
This PR changes a file inside HIR ty lowering was modified cc @fmease |
BoxyUwU
commented
Apr 24, 2025
|
☔ The latest upstream changes (presumably #140388) made this pull request unmergeable. Please resolve the merge conflicts. |
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
3361c7d to
34ce403
Compare
4 tasks
compiler-errors
approved these changes
May 22, 2025
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 22, 2025
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#135562 (Add ignore value suggestion in closure body) - rust-lang#139635 (Finalize repeat expr inference behaviour with inferred repeat counts) - rust-lang#139668 (Handle regions equivalent to 'static in non_local_bounds) - rust-lang#140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths) - rust-lang#140435 (use uX::from instead of _ as uX in non - const contexts) - rust-lang#141130 (rustc_on_unimplemented cleanups) - rust-lang#141286 (Querify `coroutine_hidden_types`) Failed merges: - rust-lang#140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs) r? `@ghost` `@rustbot` modify labels: rollup
|
☔ The latest upstream changes (presumably #141396) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
S-waiting-on-author
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
2 times, most recently
from
aee1a22 to
701d3b8
Compare
|
I should probably update this to use DeepRejectCtxt and handle LTAs correctly like discussed at the all hands 🤔 I was just gonna do it in a followup PR but if I'm having to rebase and figure out new crashes tests then I may aswell just do it all now |
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
701d3b8 to
276daf2
Compare
BoxyUwU
commented
May 23, 2025
lcnr
reviewed
May 23, 2025
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
276daf2 to
5867bb5
Compare
BoxyUwU
commented
May 23, 2025
This comment has been minimized.
This comment has been minimized.
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
5867bb5 to
02b87a8
Compare
BoxyUwU
commented
May 23, 2025
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
f4e04a9 to
ae65625
Compare
lcnr
reviewed
Jun 17, 2025
lcnr
reviewed
Jun 17, 2025
lcnr
reviewed
Jun 17, 2025
lcnr
reviewed
Jun 17, 2025
tests/ui/associated-inherent-types/multiple-candidates-in-adt-field-2.rs
Outdated
Show resolved
Hide resolved
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
Kobzol
added a commit
to Kobzol/rust
that referenced
this pull request
Jun 18, 2025
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs Fixes rust-lang#108491 Fixes rust-lang#125879 This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE Fixes rust-lang#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE) Fixes rust-lang#138131 Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality. This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful. I'm not really sure how this interacts with rust-lang#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that. r? `@compiler-errors` cc `@fmease`
|
@bors r- PR CI failed. |
bors
added
S-waiting-on-author
BoxyUwU
force-pushed
the
iats_no_query_cycles
branch
from
e280d26 to
377d8fa
Compare
|
@bors r=lcnr |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jun 19, 2025
Rollup of 7 pull requests Successful merges: - #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs) - #142507 (use `#[align]` attribute for `fn_align`) - #142524 (Weekly `cargo update`) - #142606 (AsyncDrop trait without sync Drop generates an error) - #142639 (Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs) - #142654 (library: Increase timeout on mpmc test to reduce flakes) - #142692 (Assorted bootstrap cleanups (step 3)) r? `@ghost` `@rustbot` modify labels: rollup
github-project-automation
bot
moved this from In Progress
to Done
in Inherent Associated Types (IAT)
rust-timer
added a commit
that referenced
this pull request
Jun 19, 2025
Rollup merge of #140247 - BoxyUwU:iats_no_query_cycles, r=lcnr Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs Fixes #108491 Fixes #125879 This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE Fixes #136678 (but no test added, I don't rly care about weird IAT edge cases under GCE) Fixes #138131 Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality. This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful. I'm not really sure how this interacts with #126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that. r? `@compiler-errors` cc `@fmease`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #108491
Fixes #125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixes #136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixes #138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a
ParamEnv. I replaced it with a useDeepRejectCtxtwhich should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with #126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support
T::Assoc::Otherfor trait-associated types so didn't give much thought to how this might fit in with that.r? @compiler-errors
cc @fmease