Don't build ParamEnv and do trait solving in ItemCtxts when lowering IATs#140247
Merged
bors merged 5 commits intorust-lang:masterfrom Jun 19, 2025
Merged
Don't build ParamEnv and do trait solving in ItemCtxts when lowering IATs#140247bors merged 5 commits intorust-lang:masterfrom
ParamEnv and do trait solving in ItemCtxts when lowering IATs#140247bors merged 5 commits intorust-lang:masterfrom
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 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.
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