Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Accept
Enum::<Param>::Variant {}
overEnum::Variant::<Param> {}
#69363Accept
Enum::<Param>::Variant {}
overEnum::Variant::<Param> {}
#69363Changes from all commits
aafdbb6
0339831
9d58e12
63379aa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Two things here:
p.segments
.args.is_some()
is the correct way to check this, it might be true even for::<>
which I'm not sure if it's compatible with the similar check in typeckExpr::Struct
right now (<Enum>::Variant {...}
is not valid syntax, andEnum::Variant
is not valid in type paths yet, only one of these two could actually be relevant here)Enum::Variant {...}
are therefore inaccurate IMOenum
variant types so you could just as well add an assert thatDefKind::Variant
parts are neverParamMode::Explicit
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.
I'm not sure I would include
CTOR
in the name. Also, this isn't limited to type parameters.I'd call it
VARIANT_GENERICS
orVARIANT_GENERIC_ARGS
.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.
I think this is unnecessarily complicated, it doesn't distinguish this "
enum
vs variant" situation from others (e.g. trying to pass generic args to amod
) and it's wrong with generic associated items like methods or GATs.This could be a help message on the error from
prohibit_generics
, such as pointing to theenum
segment and saying "this segment already specified generic args for theenum
" or something.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.
That check is being done when called. If it were called without that check it would indeed be incorrect.
Wanted to separate this from E0109 to potentially give it its own error code to explain that this will never be supported as opposed to the more generic current error.
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.
What do you mean? Generics on both the
enum
and a variant is a plausible feature (GADT), and generics on modules have been talked about in the past.The error message looks pretty misleading to me, it seems to claim some absolute truth.
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.
I don't like this check, and you can get rid of the lifetimes for now (they shouldn't be added to value paths anyway).
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.
Agree. It's hacky as hell.
How?
I've spent too much time trying to figure out of a way of making this change without affecting currently accepted code.
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.
Basically you want all
Expr::Struct
with variant paths to behave in HRI lowering like they did when you had removed theDefKind::Variant
arm.You don't want the elision lifetimes being injected at all.
They're for
fn foo(x: &T) -> Enum::Variant
, or perhaps<Enum>::Variant {...}
(neither of which compile right now), notEnum::Variant {...}
.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.
But if none of the PathSegments have the elision lifetimes injected (in src/librustc_ast_lowering/path.rs) then you get knock down errors about the type for a HirId not existing .
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.
I don't recall you bringing this up, I thought it just worked while you had that arm removed? I don't see why it would, other value paths have no lifetimes injected into them at all.