Run normalize_projection_ty in Canonical mode

[jyn514]

This allows recovering from overflow errors when normalizing a type.

This would have prevented the regression in #79506 (comment). I don't yet have a test, since normalization in rustdoc was reverted (#79469). If you want me to add one, I can add a -Z normalize-docs flag to rustdoc and use it in the test.

r? @Aaron1011 for review or reassignment.

[jyn514]

This is just cleanup, I can move it to a separate PR if you like.

[Aaron1011]

I'm pretty sure that this is incorrect - the projection code shouldn't have it's behvaior changed just at for rustdkc.

Instaed, I think we need a way of enabling this only for the specific part of rustdoc that needs it.

[jyn514]

What about adding InferCtxt::query_mode: Option<TraitQueryMode> that can be used to override the default mode?

[jyn514]

Hmm, actually that might be tricky since rustc_infer doesn't currently depend on rustc_trait_selection :( I could move TraitQueryMode to rustc_infer instead?

[jyn514]

@Aaron1011 can you explain more about why using Canonical would be wrong for rustc (as opposed to rustdoc)?

[Aaron1011]

I'm not very familiar with the details of how normalization works, but the current mode was chosen for a reason, and changing it will almost certainly have wider consequences.

[Aaron1011]

cc @matthewjasper

[jyn514]

ping @matthewjasper - do you know why it was in Standard mode before? If this change is wrong, do you have an alternative suggestion for how to make this work for rustdoc? For context, this is meant to avoid one of the process::exits when normalizing a type and the type-length limit gets hit, because rustdoc normalizes associated items the user didn't ask to normalize.

[jyn514]

ping @matthewjasper. I would prefer not to special case rustdoc here but I can if you think it makes more sense.

[jyn514]

Closing in favor of #81091.