Check associated const binding types

[YUZHEthefool]

For situations such as fn() that cannot be used as type system constant types, normal E0741 is generated in advance and the error type is returned to avoid continuing to enter constant evaluation and trigger ICE.
Fix: #161100

[rustbot]

HIR ty lowering was modified

cc @fmease

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @mu001999 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

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

[mu001999]

Could you remove this? I think it's okay to track the stderr for this case.

View changes since the review

[YUZHEthefool]

Ok, I will remove it, and fix the current ci problem and submit it together.

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

test [crashes] tests/crashes/148621.rs ... ok
test [crashes] tests/crashes/148629.rs ... ok
test [crashes] tests/crashes/138361.rs ... ok
test [crashes] tests/crashes/148888.rs ... ok
2026-08-15T13:17:35.497974Z ERROR compiletest::runtest: fatal error, panic: "crashtest no longer crashes/triggers ICE, hooray! Please give it a meaningful name, add a doc-comment to the start of the test explaining why it exists and move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description ensures that the corresponding ticket is auto-closed upon merge. If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`."
test [crashes] tests/crashes/148632.rs ... FAILED
test [crashes] tests/crashes/148890.rs ... ok
test [crashes] tests/crashes/149162.rs ... ok
test [crashes] tests/crashes/149809.rs ... ok
test [crashes] tests/crashes/150049.rs ... ok
---

---- [crashes] tests/crashes/148632.rs stdout ----
------rustc stdout------------------------------

------rustc stderr------------------------------
error[E0658]: associated const equality is incomplete
##[error] --> /checkout/tests/crashes/148632.rs:9:25
  |
9 |     let _: &dyn Project<SELF = { 0 }>;
  |                         ^^^^^^^^^^^^
  |
  = note: see issue #132980 <https://github.com/rust-lang/rust/issues/132980> for more information
  = help: add `#![feature(min_generic_const_args)]` to the crate attributes to enable
  = note: this compiler was built on 2026-08-15; consider upgrading it if it is out of date

error[E0741]: `(dyn D<FreshTy(0)> + 'static)` can't be used as a const parameter type
##[error] --> /checkout/tests/crashes/148632.rs:9:25
  |
9 |     let _: &dyn Project<SELF = { 0 }>;
  |                         ^^^^

error[E0038]: the trait `Project` is not dyn compatible
##[error] --> /checkout/tests/crashes/148632.rs:9:17
  |
9 |     let _: &dyn Project<SELF = { 0 }>;
  |                 ^^^^^^^^^^^^^^^^^^^^^ `Project` is not dyn compatible
  |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
 --> /checkout/tests/crashes/148632.rs:5:11
  |
---
For more information about an error, try `rustc --explain E0038`.

------------------------------------------

error: crashtest no longer crashes/triggers ICE, hooray! Please give it a meaningful name, add a doc-comment to the start of the test explaining why it exists and move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description ensures that the corresponding ticket is auto-closed upon merge. If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`.

thread '[crashes] tests/crashes/148632.rs' panicked at src/tools/compiletest/src/runtest/crashes.rs:16:18:
fatal error
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- [crashes] tests/crashes/148632.rs stdout end ----

[mu001999]

I don't think E0741 is suitable to be emitted here. In this case, F is not even a const generic parameter or type const, it is a associated const instead. 🤔

[YUZHEthefool]

So what diagnosis should be generated here?and whether associated constant equality of non-ConstParamTy types should be rejected here

[mu001999]

I think maybe we could emit something like what we did for the following:

const f1: fn() = || {};
const f2: fn() = || {};

const r: bool = f1 == f2;

And for now we will get:

error: pointers cannot be reliably compared during const eval
 --> src/lib.rs:4:17
  |
4 | const r: bool = f1 == f2;
  |                 ^^^^^^^^
  |
  = note: see issue #53020 <https://github.com/rust-lang/rust/issues/53020> for more information

[YUZHEthefool]

Ok, I will make changes based on this direction

[mu001999]

and whether associated constant equality of non-ConstParamTy types should be rejected here

IIUC, ConstParamTy is used for adt_const_params and type const. For GCA, we don't need it:

#![feature(generic_const_args)]
#![feature(min_generic_const_args)]
#![allow(incomplete_features)]

enum Foo {
    A,
    B,
    C,
}

trait Trait {
    const X: Foo;
}

fn foo(x: impl Trait<X = { Foo::A }>) {}

This could compile successfully, and we don't need to mark ConstParamTy.

---

For adt_const_params/type const, we will need ConstParamTy:

#![feature(adt_const_params)]
#![allow(incomplete_features)]

enum Foo {
    A,
    B,
    C,
}

struct Bar<const X: Foo>();

will produce:

error[E0741]: `Foo` must implement `ConstParamTy` to be used as the type of a const generic parameter
  --> main.rs:10:21
   |
10 | struct Bar<const X: Foo>();
   |                     ^^^
   |
help: add `#[derive(ConstParamTy, PartialEq, Eq)]` to the enum
   |
 4 + #[derive(ConstParamTy, PartialEq, Eq)]
 5 | enum Foo {
   |

[YUZHEthefool]

Ok,so the correct boundary is not "whether the type implements ConstParamTy", but "whether this specific constant can form a stable value for type system equality",its right?

[mu001999]

I'm not sure what's the appropriate solution. At least for myself, I don't think checking in lower_assoc_item_constraint is good enough.

r? BoxyUwU, do you have time to have a look?

[rustbot]

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

[YUZHEthefool]

Ok, I will stop my current repair work.I have almost implemented the usage context based on:nonSupportedType passed to associated equality, and then generate the pointer comparison diagnosis required by the maintainer for the function pointer.