Fix type resolution of associated const equality bounds (take 2)

[fmease]

Instead of trying to re-resolve the type of assoc const bindings inside the type_of query impl in an incomplete manner, transfer the already (correctly) resolved type from add_predicates_for_ast_type_binding to type_of/anon_type_of through query feeding.

---

Together with #118668 (merged) and #121258, this supersedes #118360.
Fixes #118040.

r? @ghost

[fmease]

This might leak {type error} since we haven't actually resolved & feed the type to type_of(AnonConst) if we reach this case. The pretty-printer doesn't seem to care though (not sure if it can actually crash on certain inputs involving ty::TyKind::Error though).

Alternatively, I could pretty-print the HIR of the const but I'd need to create a public helper, const_to_string, since rustc_hir_pretty doesn't seem to expose anything like that yet?

[fmease]

Best reviewed commit by commit.
r? compiler-errors (no rush though)

[fmease]

We can directly feed the AnonConst's type instead of adding another indirection.

Oh, that makes perfect sense, thanks! Apart from eliminating indirection, does your change affect incremental query evaluation? Just out of curiosity I'd like to ask if the previous approach was unsound?

As for next steps, is this change ready to be merged? Who should review it lol?

[oli-obk]

Just out of curiosity I'd to ask if the previous approach was unsound?

It fed a hir id query, which we haven't considered yet at all. We could have marked whichever query did that as depending on the forever red node, meaning it would get rerun always. That would have been sound, but horrible for perf.

Then again, it's not really worse than what I did with the other query, just fewer moving parts. Also DefIds are a bit more stable than hir ids, due to their tree style relative nature.

I did not think about hir id query feeding soundness too much, so it may have been fine

[oli-obk]

Just out of curiosity I'd to ask if the previous approach was unsound?

It fed a hir id query, which we haven't considered yet at all. We could have marked whichever query did that as depending on the forever red node, meaning it would get rerun always. That would have been sound, but horrible for perf.

Then again, it's not really worse than what I did with the other query, just fewer moving parts. Also DefIds are a bit more stable than hir ids, due to their tree style relative nature.

I did not think about hir id query feeding soundness too much, so it may have been fine

As for next steps, is this change ready to be merged? Who should review it lol?

We can cross review each other's changes 😅 or get cjgillot to chime in

[fmease]

Hey, @cjgillot. If you have time and energy, could you skim this PR and double-check if the query feeding performed here roughly makes sense from a soundness perspective wrt. incr comp? Thanks a lot in advance!

We can cross review each other's changes

Otherwise the changes look good to me!

[cjgillot]

LGTM. Sorry for the delay.
@bors r=oli-obk,cjgillot

[bors]

📌 Commit 858d336 has been approved by oli-obk,cjgillot

It is now in the queue for this repository.