Skip to content

Presence of lifetime generics on free const items should not affect if const is checked for evaluatability #136204

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.

Sign up for GitHub

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

Jump to bottom
Open
compiler-errors opened this issue Jan 28, 2025 · 0 comments
Open

Presence of lifetime generics on free const items should not affect if const is checked for evaluatability #136204

compiler-errors opened this issue Jan 28, 2025 · 0 comments
Assignees
@fmease
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
@fmease fmease mentioned this issue Feb 2, 2025
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 2, 2025
@bors
Auto merge of rust-lang#136429 - fmease:gci-fix-def-site-checks, r=<try>
ea1cdda 
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
@bors
Auto merge of rust-lang#136429 - fmease:gci-fix-def-site-checks, r=<try>
6f11489 
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
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2025
@bors
Auto merge of rust-lang#136429 - fmease:gci-fix-def-site-checks, r=<try>
3f34812 
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
jhpratt added a commit to jhpratt/rust that referenced this issue May 29, 2025
@jhpratt
Rollup merge of rust-lang#136429 - fmease:gci-fix-def-site-checks, r=…
d3c605a 
…BoxyUwU

GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants

* 1st commit: Partially addresses [rust-lang#136204](rust-lang#136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
  * As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
  * With this PR, both become pre-mono ones!
* 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 `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue rust-lang#113521.

r? compiler-errors or reassign
rust-timer added a commit that referenced this issue May 29, 2025
@rust-timer
Unrolled build for #136429
29b2bfb 
Rollup merge of #136429 - fmease:gci-fix-def-site-checks, r=BoxyUwU

GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants

* 1st commit: Partially addresses [#136204](#136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
  * As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
  * With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!

This doesn't fully address #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 `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.

r? compiler-errors or reassign
@fmease fmease changed the title Lifetime generics on Generic Const Items should not affect if const is checked for evaluatability Presence of lifetime generics on free const items should not affect if const is checked for evaluatability May 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fmease fmease

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
Generic Const Items (GCI)
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
3 participants
@compiler-errors @fmease @rustbot