Skip to content

yeet AliasConstKind::opt_def_id - #162797

Open
khyperia wants to merge 1 commit into
rust-lang:mainfrom
khyperia:yeet-opt_def_id
Open

khyperia wants to merge 1 commit into
rust-lang:mainfrom
khyperia:yeet-opt_def_id

Conversation

@khyperia

Copy link
Copy Markdown
Member

A while back, I made three PRs removing def_id from AliasConst/AliasTerm/AliasTy:

I did AliasConst first, and due to my inexperience with this refactor, I had this opt_def_id kludge. I didn't do the same thing in the AliasTy or AliasTerm PRs. It ought to be removed and replaced with explicit matches.

This PR conflicts with #162760 - please merge that one first! the code in this PR is a bit kludgey until that PR is merged.

related tracking-ish issues:

r? @BoxyUwU

@rustbot

rustbot commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred in abstract_const.rs

cc @BoxyUwU

Some changes occurred in match checking

cc @Nadrieril

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 Sep 15, 2026
@rustbot

rustbot commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

@bit-aloo bit-aloo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@BoxyUwU BoxyUwU left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

// we are not instantiating the result, so it's OK here.
def_id
}
ty::AliasConstKind::InherentImpl { def_id } => def_id,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

is inherent impl reachable here? the type from const_param_default ought to be unnormalized and so in InherentSelf form

@khyperia khyperia Sep 16, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

it is unreachable. it is from const_param_default->lower_const_arg->lower_type_relative_const_path->blah blah unnormalized. the rest are reachable though (at first I was like "can't it only be anons?" but no it can be directly represented paths too)

}
Res::Def(DefKind::Const, did) => {
if let Err(guar) = self.check_const_item_in_type_system(did, span) {
let alias_const_kind = ty::AliasConstKind::new_from_def_id(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

given that this is never an inherent const it would be nice to use a different constructor here that doesnt take AliasConstInherentArgsKind

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

#162760 I suppose

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

exactly:

This PR conflicts with #162760 - please merge that one first! the code in this PR is a bit kludgey until that PR is merged.

(this is one of the kludgey spots)

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.

4 participants