Skip to content

MGCA: require #[type_const] on free consts too#152129

Open
khyperia wants to merge 1 commit intorust-lang:mainfrom
khyperia:require-type_const-on-free-consts
Open

MGCA: require #[type_const] on free consts too#152129
khyperia wants to merge 1 commit intorust-lang:mainfrom
khyperia:require-type_const-on-free-consts

Conversation

@khyperia
Copy link
Contributor

@khyperia khyperia commented Feb 4, 2026

When investigating another issue, I discovered that following ICEs (the const_of_item query doesn't support non-type_const-marked constants and does a span_delayed_bug):

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

const N: usize = 4;

fn main() {
    let x = [(); N];
}

My initial thought of "only require #[type_const] on places that stable doesn't currently accept" ran into the issue of this compiling on stable today:

trait Trait {
    const N: usize;
}

impl<const PARAM: usize> Trait for [(); PARAM] {
    const N: usize = PARAM;
}

fn main() {
    let x = [(); <[(); 4] as Trait>::N];
}

Figuring out which specific cases are not currently accepted by stable is quite hairy.

Upon discussion with @BoxyUwU, she suggested that all consts, including free consts, should require #[type_const] to be able to be referred to. This is what this PR does.


The change to tests/ui/const-generics/generic_const_exprs/non-local-const.rs is unfortunate, reverting the fix in #143106 no longer fails the test. Any suggestions to test it more appropriately would be most welcome!

edit: never mind, figured out how compiletests work :) - verified that the new test setup correctly ICEs when that PR's fix is reverted.

r? @BoxyUwU

@rustbot
Copy link
Collaborator

rustbot commented Feb 4, 2026

HIR ty lowering was modified

cc @fmease

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 4, 2026
@khyperia khyperia force-pushed the require-type_const-on-free-consts branch from 2802eb1 to 63e1045 Compare February 4, 2026 19:01
} else {
None
};
self.lower_resolved_assoc_const_path(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting, I'd have thought you'd have needed to update AssocConst too but lower_resolved_assoc_const_path already handles it. That's fun

@khyperia khyperia force-pushed the require-type_const-on-free-consts branch from 63e1045 to 0db0759 Compare February 5, 2026 12:53
def_id: DefId,
span: Span,
) -> Result<(), ErrorGuaranteed> {
if find_attr!(self.tcx().get_all_attrs(def_id), AttributeKind::TypeConst(_)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if find_attr!(self.tcx().get_all_attrs(def_id), AttributeKind::TypeConst(_)) {
if self.tcx().is_type_const(def_id) {

should work instead and be a bit shorter/nicer :3

note: the declaration must be marked with `#[type_const]`
--> $DIR/unmarked-free-const.rs:6:1
|
LL | const N: usize = 4;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pointing to the definition site of the non-type const is rly nice :3 thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants