Skip to content

const_evaluatable_unchecked FCW applies to all kinds of const evaluation not just of repeat expr const args #140447

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

Closed
BoxyUwU opened this issue Apr 29, 2025 · 0 comments · Fixed by #140467
Assignees
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-const-generics Area: const generics (parameters and arguments) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@BoxyUwU
Copy link
Member

BoxyUwU commented Apr 29, 2025

Ran into this warning and wanted to share my confusion with it. My confusion stems from the fact that this warning seems to be triggered inconsistently. Example of this

pub struct Example<const CONSTANT: u32>;

impl<const CONSTANT: u32> Example<CONSTANT> {
    const DOESNT_CHANGE: usize = 3;
    const ALSO_DOESNT_CHANGE: usize = Self::DOESNT_CHANGE;
    
    pub fn does_trigger_warning(&self, i: usize) -> usize {
        match i {
            Self::ALSO_DOESNT_CHANGE => 0,
            _ => 1
        }
    }
    
    pub fn doesnt_trigger_warning(&self, i: usize) -> usize {
        match i {
            Self::DOESNT_CHANGE => 0,
            _ => 1
        }
    }
    
    pub fn also_doesnt_trigger_warning(&self, i: usize) -> usize {
        if i == Self::ALSO_DOESNT_CHANGE {
            0
        } else {
            1
        }
    }
}

The other thing that I found confusing was that the warning shows up on the declaration of DOESNT_CHANGE and not the usage (which is what caused the warning to appear).

I am using cargo 1.88.0-nightly (d811228b1 2025-04-15) and rustc 1.88.0-nightly (077cedc2a 2025-04-19).

Originally posted by @MorganBennetDev in #76200

@BoxyUwU BoxyUwU added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-const-generics Area: const generics (parameters and arguments) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 29, 2025
@BoxyUwU BoxyUwU self-assigned this Apr 29, 2025
Zalathar added a commit to Zalathar/rust that referenced this issue Apr 30, 2025
Don't FCW assoc consts in patterns

Fixes rust-lang#140447

See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
Zalathar added a commit to Zalathar/rust that referenced this issue Apr 30, 2025
Don't FCW assoc consts in patterns

Fixes rust-lang#140447

See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 30, 2025
Don't FCW assoc consts in patterns

Fixes rust-lang#140447

See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 30, 2025
Don't FCW assoc consts in patterns

Fixes rust-lang#140447

See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 30, 2025
Rollup merge of rust-lang#140467 - BoxyUwU:no_fcw_assoc_consts, r=lcnr

Don't FCW assoc consts in patterns

Fixes rust-lang#140447

See comment in added test. We could also check that the anon const is a const arg by looking at the HIR. I'm not sure that's necessary though 🤔 The only consts that are evaluated "for the type system" are const args (which *should* get FCWs) and const patterns (which cant be anon consts afaik).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-const-generics Area: const generics (parameters and arguments) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant