Do not ICE when failing to fulfill known obligations due to normalization

[cjgillot]

Part of #91743

r? @jackh726

[Aaron1011]

Isn't this potentially unsound, if the errors produced were legitimate?

[cjgillot]

Overzealous normalization may "lose" some bounds. In the test, mk_cycle is instanciated with try_execute_query's C::V, which implements Debug because of the bound in Cache. When inlined, mk_cycle is instanciated with get_query's Q::V (identical to <Q::C as Cache>::V, but the trait solver may have forgot this type Debug.

Normally, all the bounds would have been proven by trait inference, hence this is a delay_span_bug.

@Aaron1011, I agree. This PR can be reframed into the following question: how to separate legitimate from illegitimate errors, to make all this sound?

[jackh726]

This doesn't seem correct - especially not in isolation. The test passes on current nightly; is this expected?

If there are in fact errors that pop up in #91743 for this test, then that's curious. I'd like to know exactly what the errors are.

[cjgillot]

The test only ICEs with MIR inlining. See godbolt for the error:

error: internal compiler error: Encountered errors `[FulfillmentError(Obligation(predicate=Binder(TraitPredicate(<<Q as Query>::V as std::fmt::Debug>, polarity:Positive), []), depth=0),Unimplemented)]` resolving bounds after type-checking
  |
  = note: delayed at compiler/rustc_trait_selection/src/traits/codegen.rs:125:24

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:1188:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[Aaron1011]

That looks like a bug in fulfillment (maybe something with normalization?) - maybe inlining isnt updating the ParamEnv correctly?

[jackh726]

I...think...this could be a variation of #91985.

We have type V: Debug, then type C: Cache<V = Self::V> without an explicit V: Debug bound here. Which means later we'll have to prove that. but we don't have that bound in the ParamEnv. I have a POC branch linked in that issue that might solve this, maybe take a look? (It's not 100% mergable right now, but all but like 3 tests pass).

[bors]

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

[jackh726]

I'm going to go ahead an close this. This isn't really the right approach for this. I have a branch that might fix this, but has some other things wrong that needs to be thought about. Might be worth checking out. jackh726@18042d9