Conversation
|
|
| // we are not instantiating the result, so it's OK here. | ||
| def_id | ||
| } | ||
| ty::AliasConstKind::InherentImpl { def_id } => def_id, |
There was a problem hiding this comment.
is inherent impl reachable here? the type from const_param_default ought to be unnormalized and so in InherentSelf form
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
given that this is never an inherent const it would be nice to use a different constructor here that doesnt take AliasConstInherentArgsKind
There was a problem hiding this comment.
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)
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_idkludge. 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:
Alias[Ty|Const|Term]KindintoAlias[Ty|Const|Term], generalize to not require just aDefId#152245AliasTermrefactor #156181ConstKind::UnevaluatedandTyKind::Aliasand allow non defid/subst pairs project-const-generics#98r? @BoxyUwU