Fix ICE in normalizing inherent associated consts with #[type_const]

[lapla-cogito]

Fixes#151027
Fixes#138089
Fixes#138226
Fixes#150960

When an inherent associated const is marked with #[type_const], its generics expect args in the format [Self, own_params...], similar to inherent associated types. However, HIR typeck's instantiate_value_path was constructing args in the regular associated const format [impl_params..., own_params...]. This mismatch caused ICEs when the args were later used in contexts expecting the IAC format, such as user type annotations and borrowck's type ascription.

[rustbot]

r? @nnethercote

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

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

[nnethercote]

r? @fmease

[rustbot]

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

[BoxyUwU]

If you're interested in fixing this I would recommend reading through #project-const-generics > Inherent associated consts (`IAC`) under `MGCA` as I talk there about what a proper fix for our improper handling of inherent associated consts would be

[BoxyUwU]

I expect that we'll need to make instantiate_value_path for inherent associated type consts yield proper type-system-compatible args (i.e. [Self, Gat0..N]), as well as the stuff in that thread about making the trait solvers even handle IACs correctly in the first place. Would definitely be a multi-PR kind of thing and I would probably not start with caring about instantiate_value_path

[lapla-cogito]

@BoxyUwU Thank you! I'm interested in resolving this ICE issue series, so I reviewed the thread you provided. I have several questions:

• Has the fix approach suggested in the thread already been implemented in this commit by you?
• Why do you think the instantiate_value_path modification should be deferred? Are there specific factors, such as yet unresolved issues with trait solver IAC support that depend on it?
• (This likely depends heavily on the answer above) Should this be closed? If so, I don't think I should make decisions on how to resolve this alone. What would be an appropriate approach?

[BoxyUwU]

oh apparently yes I did implement a lot of that? cool.. In that case I think the two things necessary now are:

• Update debug_assert_args_are_compatible to special case IACs not just IATs
• Make instantiate_value_path/whatever return correctly laid out arguments for type_consts

In which case doing it all in this PR seems totally reasonable :)

[lapla-cogito]

I've implemented the necessary measures to suppress the ICE (though proper handling of crashtest cases that no longer crash remains necessary). However, borrowck currently skips ascribe_user_type for IAC cases (see the added FIXME comments). I believe the "args transformation" implemented in this PR won't work for borrowck with nested items (e.g., anonymous constants), and more precise handling would require adjusting the args format in MIR. I'm unsure how much of this should be addressed in this PR.

[lapla-cogito]

Now the remaining concern is how to handle the borrowck problem that I mentioned above.

[BoxyUwU]

That test failure isn't your fault. rustdoc is broken right now, see #152194

[lapla-cogito]

Yes, I saw it just a moment ago :)

[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.

[BoxyUwU]

@bors r+ rollup

thanks :3

[rust-bors]

📌 Commit 22885d2 has been approved by BoxyUwU

It is now in the queue for this repository.