[amirHdev]

fixes #163320
the associated type suggestion probe uses an empty param-env which leaves the next solver without the const parameter's type information

we can add necessary clauses while avoiding queries for a generic parameter's type during its own lowering

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 19 candidates

[lcnr]

the fact that we use type relations at all when lowering in an ItemCtxt is kind of scuffed. What does this function exist for and could we somehow avoid relying on type relations while lowering item definitions entirely?

View changes since this review

[lcnr]

r? lcnr

[amirHdev]

Reworked this to avoid using type relations in ItemCtxt

[lcnr]

hmm, this is a lot of complexity for a kind of minor diagnostic. But also, this code is weird. why do you both have an infcx.is_none() check and then do an if let. feels nicer to only match on infcx once. We never have infcx and not a param_env, do we? so maybe we should have a single get_ctxt_if_in_body or something that returns both InferCtxt and ParamEnv

fold_regions to replace all regions with erased is wrong. We must not replace bound regions as doing so changes types.

I feel like ideally we wouldn't try to do anything interesting when in an ItemCtxt 🤔 idk what I want here. How bad is it if you always just use the deepreject check and never try a proper can_eq?

View changes since the review

[amirHdev]

I think using DeepRejectCtxt everywhere makes sense here

we might get some false positives, like (u8, u16) matching impl<T> HasItem for (T, T) but that seems acceptable for a diagnostic
we'd need to reconsider MachineApplicable though

I'll simplify the code

[amirHdev]

I noticed that DeepRejectCtxt matches unresolved projections against quite a few unrelated impls

may skipping them also loses some useful suggestions in function bodies but I think that is better than suggesting traits that do not actually apply

[rust-bors]

☔ The latest upstream changes (presumably #165234) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.