Handle nontype const inherent associated consts

[cijiugechu]

Keep non type const inherent associated consts as unevaluated consts instead, so they are evaluated normally rather than normalized as projections.

Closes #148063

[rustbot]

changes to the core type system

cc @lcnr

[rustbot]

r? @Kivooeo

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 73 candidates
• Random selection from 19 candidates

[Kivooeo]

Not confident in reviewing const stuff

@BoxyUwU could you take a look when you have time please

[BoxyUwU]

r? BoxyUwU

[rust-bors]

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

[BoxyUwU]

I need to do some thinking about how this fits into the long term plans for proper IAT/IAC support, the idea here of representing non-type consts as AliasTermKind::UnevaluatedConst and now UnevaluatedConstKind::Anon is interesting 🤔

I think it would need to look a little different than the current PR as we won't want to implicitly change stuff when converting to/from AliasTerm, instead we'd want to do this in the HIR ty lowering logic. Also, we'd want to do this for better support for IACs in generic_const_args, not for better generic_const_exprs support, which is to say we should have tests using GCA not GCE :3

I'll try and remind myself of some of the subtle issues we ran into when originally trying to support IACs in generic_const_args and then figure out how that interacts with this :) I know that @khyperia is going to spend time soon sorting out proper support for IATs/IACs which would make this PR redundant (though that work may take a while). I don't know how much effort it's worth putting into a stop-gap measure

[khyperia]

Also, we'd want to do this for better support for IACs in generic_const_args, not for better generic_const_exprs support, which is to say we should have tests using GCA not GCE :3

just fyi, there's several tests here already, for example, https://github.com/rust-lang/rust/blob/main/tests/ui/const-generics/gca/path-to-non-type-inherent-associated-const.rs

[BoxyUwU]

thinking on this more, while I think a stop-gap solution along these lines would be workable it's not clear to me that it's worth doing given @khyperia is working on a more involved change to our handling of inherent associated types/consts/typeconsts. especially since this PR would need some fairly extensive changes to be that stop-gap solution 🤔

I am, unfortunately, gonna close this PR due to this but that's not reflective of your work :3 generally though, thanks for taking an interest in this and I can find you some other const generics stuff to work on if you'd like :3 if you haven't already come say hi on the #project-const-generics zulip stream