-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Lower multi-segment const paths as ConstArgKind::Path
#135186
base: master
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
c501669
to
4efbed3
Compare
This comment has been minimized.
This comment has been minimized.
4efbed3
to
0036c2c
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ConstArgKind::Path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx for working on this :3
@@ -1100,7 +1100,8 @@ impl<'a, 'hir> LoweringContext<'a, 'hir> { | |||
.and_then(|partial_res| partial_res.full_res()) | |||
{ | |||
if !res.matches_ns(Namespace::TypeNS) | |||
&& path.is_potential_trivial_const_arg() | |||
// FIXME: should this only allow single-segment paths? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// FIXME: should this only allow single-segment paths? | |
// FIXME(mgca): should this only allow single-segment paths? |
unannotated FIXME
will just get lost tbh, no way of tracking them down lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah, I meant it as a FIXME to deal with before merging this PR -- which is why I didn't label it. But since all of this is experimental anyway, we could deal with it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh in that case using // TODO
will fail tidy and ensure the PR can't be merged until its resolved which ensures noone can forget about it before r+
compiler/rustc_ast/src/ast.rs
Outdated
/// Could this expr be either `N`, or `{ N }`, where `N` is a const parameter. | ||
/// | ||
/// If this is not the case, name resolution does not resolve `N` when using | ||
/// `min_const_generics` as more complex expressions are not supported. | ||
/// | ||
/// Does not ensure that the path resolves to a const param, the caller should check this. | ||
/// This also does not consider macros, so it's only correct after macro-expansion. | ||
pub fn is_potential_trivial_const_arg(&self) -> bool { | ||
pub fn is_potential_trivial_const_arg(&self, allow_multi_segment: bool) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not that just we should support multi seg paths we should also support generic arguments on paths too, and also support qualified paths. e.g. this path which has segments with args and also a self ty: <T as Trait<u32>>::ASSOC
/// Literals and const generic parameters are eagerly converted to a constant, everything else | ||
/// becomes `Unevaluated`. | ||
#[instrument(level = "debug", skip(self), ret)] | ||
pub fn lower_const_assoc_path( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should definitely consolidate this and lower_assoc_path
into one method that handles 99% of the logic since the only real behavioural differences are the AssocKind
arguments we hard code and that we construct a Ty
or Const
at the very end depending on which method it is
match &candidates[..] { | ||
[] => {} | ||
&[(impl_, assoc)] => { | ||
// FIXME(mgca): adapted from temporary inherent assoc ty code that may be incorrect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here we should just make probe_inherent_assoc_ty
be able to be reused for consts somehow
@@ -549,6 +549,95 @@ impl<'tcx> HirTyLowerer<'tcx> for ItemCtxt<'tcx> { | |||
} | |||
} | |||
|
|||
fn lower_assoc_const( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would probably also be good to unify with lower_assoc_ty
somehow, at the very least it would be good to not duplicate almost 100 lines of diagnostics logic :3
263637d
to
a296ff8
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
This PR:
hir::ConstArgKind::Path
ty::ConstKind::Unevaluated
#[type_const]
attribute for trait assoc consts that are allowed as const argsNext steps:
#[type_const]
if present (basically is it a const path or monomorphic anon const)r? @BoxyUwU