[YUZHEthefool]

View all comments

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]

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.

[rustbot]

Some changes occurred in const_evaluatable.rs

cc @BoxyUwU

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[YUZHEthefool]

Now,NonValTree has been separated from the generic ambiguity.
Diagnostics only occur when specific values ​​need to be compared for non-type const associated equality

[mu001999]

I hope you don't mind me asking, but did you use an LLM for this? If so, please make sure to disclose its use in accordance with our policy.

[YUZHEthefool]

Nope.I have contributed to the analyzer before and know the ai guidelines of the rust community.
Maybe I may really need LLM to help me translate some content, because I am not very good at some compiler terminology. :(

[YUZHEthefool]

just add //@ normalize-stderr: "\n\n$" -> "\n" for test,and test again.

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

[khyperia]

nice, looks good to me! @BoxyUwU do you wanna take another look?

[BoxyUwU]

r? khyperia

it looks good to me :) feel free to r+ it whenever you're happy @khyperia

[khyperia]

yippee! gosh it's really nice to have this, sorry it took so long to merge ❤️

@bors r=me,BoxyUwU rollup

[rust-bors]

📌 Commit 9517075 has been approved by me,BoxyUwU

It is now in the queue for this repository.

⚠️ The following reviewer(s) could not be found: me

[khyperia]

o nej uuuh can i just

@bors r=khyperia,BoxyUwU rollup

[rust-bors]

📌 Commit 9517075 has been approved by khyperia,BoxyUwU

It is now in the queue for this repository.