Prove nested goals before const evaluation

[mehcode]

Fixes #156780.
Tracking issue: #132980.

evaluate_const_and_instantiate_projection_term handed the constant to CTFE before proving the nested goals already registered for it. Evaluation instantiates the item's body with its arguments, so an argument whose type does not match its parameter produced ill-formed MIR and ICEd the interpreter instead of the ConstArgHasType goal reporting the mismatch.

const IGNORE<const N: usize>: usize = 0; reports the mismatch today because its body never reads N.
const ADD1<const N: usize>: usize = N + 1; ICEs.

This is not specific to literals. const F: f64 = 1.0; with ADD1::<F> ICEs the same way, so checking the literal during lowering, as #156944 attempted, would not have covered it.

I'm not completely sure about the call to self.inspect.make_canonical_response. evaluate_added_goals_and_make_canonical_response records the response before evaluating nested goals so a failure still leaves an attributable proof tree. Without it every case reports:

error[E0271]: type mismatch resolving `IGNORE<1f64> == _`
  --> tests/ui/const-generics/gca/mismatched-const-arg-type.rs:49:12
   |
49 |     let _: [(); IGNORE::<1f64>];
   |            ^^^^^^^^^^^^^^^^^^^^ types differ

This adds a try_evaluate_added_goals call before each const evaluated during normalization. The tail evaluate_added_goals_and_make_canonical_response calls it again, so goals which come back ambiguous are evaluated twice.

r? @lcnr

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[lcnr]

This feels like a weaker form of what @BoxyUwU has been planning long term where we only evaluate constants with fully concrete arguments whose where-clauses hold in an empty environment. I also think mapping errors to anything but an error is very weird and we generally shouldn't change trait solver semantics for the sake of diagnostics.

Would you be up to start a conversation about this PR in https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics

@rustbot author

r? BoxyUwU

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

[mehcode]

Fair enough. Opened #project-const-generics > gating const evaluation on where-clauses (#156780) @ 💬. I'll mark this as draft for now.