Change:
<ins> error: overly complex generic constant --> $DIR/issue-90318.rs:14:8 | LL |     If<{ TypeId::of::<T>() != TypeId::of::<()>() }>: True, |        ^^-----------------^^^^^^^^^^^^^^^^^^^^^^^^ |          | |          borrowing is not supported in generic constants | = help: consider moving this anonymous constant into a `const` function = note: this operation may be supported in the future error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-90318.rs:14:10 | LL |     If<{ TypeId::of::<T>() != TypeId::of::<()>() }>: True, |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: overly complex generic constant --> $DIR/issue-90318.rs:22:8 | LL |     If<{ TypeId::of::<T>() != TypeId::of::<()>() }>: True, |        ^^-----------------^^^^^^^^^^^^^^^^^^^^^^^^ |          | |          borrowing is not supported in generic constants | = help: consider moving this anonymous constant into a `const` function = note: this operation may be supported in the future error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-90318.rs:22:10 | LL |     If<{ TypeId::of::<T>() != TypeId::of::<()>() }>: True, |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0015`. </ins>

Discussion:
features: constgenerics constevaluatablechecked cargo doc running the rustdoc command manually without --crate-version <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pbacktrace from the rustdoc command (without --crate-version) </p</details
ICE still occurs on with feature flags changed to
With a bit of modification, this ICE happens on when running rather than ():

In some cases compiler panicks when, I believe, computing const generic argument containing , where is some closure type. Interestingly, it works well when I put closure into associated type, so expression looks like . Changing closure type to something more simple makes everything fine. This gives panic: () Interestingly, following code also requires closure type to be ZST, but compiles well: () <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +A-closures +A-zst
sorry for bothering you, but probably ZST is not a real cause of a problem. I'm very far from compiler internals, but it looks like issue is coming from using in const generics using incomplete feature . Sorry if title was inaccurate. Unfortunately I do not know what tags may be more suitable here and even can't edit them. Upd: Making closure non-ZST still crashes the compiler:
After googling a bit I finally learned how to become a better contributor :) label +F-constevaluatablechecked +A-const-eval +F-const_generics +A-const-generics -A-zst
That's quite alright! You don't need to worry about bothering me. I appreciate any advice on how to make my categorizations more helpful. That said, I might suggest editing the title and opening post to make the probable source of the problem a bit more clear. :) label +requires-nightly

I found this ICE while playing with const generics on the Rust playground. () : <details<summary<strongBacktrace</strong</summary<p</p</details
Ah, it looks like that feature enables extra behavior for s.
glacier ""
This ICEs since modify labels: +regression-from-stable-to-stable
This seems to need unstable features to reproduce? Or did I miss something?
You can reproduce the ICE on stable, but to actually use the code you need to be on nightly. I think makes sense here.
Oh, so you need the feature gates, but you can still reproduce it on stable, got it. In that case it is technically not since you can reproduce the ICE on stable.
Assigning and removing as in the prioritization working group.
would fix the ICE. To me it looks as if the problem is that the bound is not satisfied in this example, but we get a really confusing error message now: I suggest we'd close this issue and open a new diagnostics issue in case the PR would be merged.