Skip to content

Conversation

@mu001999
Copy link
Contributor

@mu001999 mu001999 commented Jan 18, 2026

Fixes #151273

As #151273 (comment) shows, I think emitting error when meeting #[cfg_attr(pred, type_const)] is good enough for now.

r? @BoxyUwU

@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 Jan 18, 2026
@petrochenkov
Copy link
Contributor

Whatever type_const is, it must never require hacks like this.

@BoxyUwU
Copy link
Member

BoxyUwU commented Jan 18, 2026

Yeah I think this should get replaced by actual syntax. Having an attribute which doesn't actually work like other attributes is just wrong:tm: We should remove #[type_const] and replace it with proper parser support now that things are further along, that way we won't have a broken attribute :)

@mu001999 if you reach out on zulip I can talk a bit more about this. Thanks for the PR though :3

@BoxyUwU BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 19, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 5, 2026

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

@mu001999 mu001999 closed this Feb 5, 2026
@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 5, 2026
@mu001999 mu001999 deleted the fix/151273 branch February 5, 2026 11:34
@mu001999 mu001999 restored the fix/151273 branch February 5, 2026 11:34
rust-bors bot pushed a commit that referenced this pull request Feb 9, 2026
Update mgca to use `type const` syntax instead of the `#[type_const]` attribute. 

This PR changes the `#[type_const]` attribute to the `type const` syntax for  #132980.

This will fixes #151273 and similar issues, since we need to check `type const` of items before expansion. The move to add a syntax was mentioned here: #151289 (comment)

The first part of this PR adds support by allowing `type const <IDENT>: <TYPE> { = <EXPR> };` syntax in `rustc_parse/src/parser/item.rs`.

The next part since the AST item does not contain enough information to determine if we have a `type const` was rework `ConstItemRhs` into `ConstItemRhsKind` to store the information since we no longer have the attribute acting as a source of extra data/metadata. 

The hir node `ConstItemRhsKind` current shape mostly works, except in the case of `TraitItemKind` where it is an option. I initially went about giving `hir::ConstItemRhsKind` a similar form the AST, but it touches a lot more lines of code and files so because of that, the less invasive option was to add a simple boolean flag to `TraitItemKind`. 

The forth part of this PR includes adding a query I called `is_rhs_type_const` so that we can handle both local and foreign def_ids. 

The fifth aspect of the PR is adding a `mgca_type_const_syntax` feature gate that is checked before expansion. The standard mgca feature gate is ran after expansion. This feature gate allows for conditional compilation (e.g #[cfg(..)]) of the `type const` syntax  in nightly without `min_generic_const_args` being enabled. 

The last bit is updating all the the tests that used the `#[type_const]` attribute to use the new syntax that failed because of the changes. This is the bulk of touched/edited files in the PR. 

r? @BoxyUwU 
@rustbot label +F-associated_const_equality +F-min_generic_const_args
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

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.

ICE: thir_body queried for type_const (via cfg_attr)

4 participants