Do not try to reveal hidden types when trying to prove Freeze in the defining scope

[oli-obk]

fixes #99793

this avoids the cycle error by just causing a selection error, which is not fatal. We pessimistically assume that freeze does not hold, which is always a safe assumption.

[rustbot]

r? @estebank

rustbot has assigned @estebank.
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

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[oli-obk]

Reassigning reviewer because it allows more code on stable and needs trait system reviews

[lcnr]

happy with this change in general, unless this blocks the stabilization of ATPIT I would wait until #122077 is merged for an in-depth review

[oli-obk]

This PR is low priority and deserves some mir_const_qualifs cleanups and reduplications before landing anyway. The other two PRs this one is based on are needed for ATPIT

[oli-obk]

I would like to make more code compile by avoiding unnecessary (and false) query cycles in Freeze bound checking during const checks. Specifically, the following code snippet should compile (it doesn't before this PR):

const fn f() -> impl Eq {
    g()
}
const fn g() {}

The reason is that when checking whether the return type implements Freeze we end up trying to reveal the opaque type. Since we're also defining the opaque type, this causes a cycle. What this PR instead does (which is what the new solver already does), is to never reveal opaque types for auto traits if we're in the defining scope. Instead, we just bail out with a non-fatal selection error. This means we do not know the answer, but if the code asking cares only about knowing for sure a trait is implemented, but is fine pessimistically assuming it is not, then we can just do that. This means that even if the hidden type is Freeze, we assume it is not, which is always a safe decision, even if it means some code won't compile even though it could.

@rfcbot merge

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[lcnr]

As a quick note: this differs from the new solver in that the new solver instead normalizes the opaque type by looking at the opaque type storage, so the new solver may instead return ambiguity or success instead of NoSolution. The important part is that the new solver new gets query cycles here, so moving to the new solver will not cause any breakage.

Theoretically the incompleteness of the old solver may guide type inference, but as there are no trait implementations with Freeze bounds this should not happen. Even if it could, it would still be merely a theoretical concern.

@rfcbot reviewed