Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lifetime generics on Generic Const Items should not affect if const is checked for evaluatability #136204

Open
compiler-errors opened this issue Jan 28, 2025 · 0 comments
Assignees
Labels
C-bug Category: This is a bug. F-generic_const_items `#![feature(generic_const_items)]` T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@compiler-errors
Copy link
Member

There's a difference between const _: () = panic!(); and const _<'a>: () = panic!();: The former is a pre-mono error, the latter is a post-mono error.

This seems inconsistent, and pretty bad. But luckily something we can change before stabilizing generic consts :)

I think we should probably change the code introduced in #121387 to instead call requires_monomorphization instead of is_empty on the generics.

It should also preferably check for impossible predicates in the same way we do for -Clink-dead-code/-Zcollect-mono-items=eager, since we must avoid monomorphizing consts with impossible (possibly trivial) preds. You could probably turn that into an ICE today.

Originally posted by @compiler-errors in #136168 (review)

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 28, 2025
@compiler-errors compiler-errors added T-types Relevant to the types team, which will review and decide on the PR/issue. F-generic_const_items `#![feature(generic_const_items)]` C-bug Category: This is a bug. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jan 28, 2025
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 2, 2025
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants

1st commit: Partially addresses rust-lang#136204 by turning const eval errors from post to pre-mono for free lifetime-generic constants.
Re. 2nd commit: Oof, that's embarrassing! How could I miss that in the initial impl?

This doesn't fully address rust-lang#136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `#![feature(trivial_bounds)] const _UNUSED: () = () where String: Copy;` which can also be found over at the tracking issue rust-lang#113521.

r? compiler-errors or reassign
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 3, 2025
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants

1st commit: Partially addresses rust-lang#136204 by turning const eval errors from post to pre-mono for free lifetime-generic constants.
Re. 2nd commit: Oof, yeah, I missed that in the initial impl!

This doesn't fully address rust-lang#136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `#![feature(trivial_bounds)] const _UNUSED: () = () where String: Copy;` which can also be found over at the tracking issue rust-lang#113521.

r? compiler-errors or reassign
@fmease fmease moved this to In Progress in Generic Const Items (GCI) Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-generic_const_items `#![feature(generic_const_items)]` T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
Status: In Progress
Development

No branches or pull requests

3 participants