-
Notifications
You must be signed in to change notification settings - Fork 439
Disallow the self
/Self
keyword where it’s not allowed in types
#1986
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
Disallow the self
/Self
keyword where it’s not allowed in types
#1986
Conversation
@swift-ci Please test |
056901f
to
f75b5fd
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
DiagnosticSpec(locationMarker: "1️⃣", message: "unexpected 'self' keyword before type"), | ||
DiagnosticSpec(locationMarker: "2️⃣", message: "expected type", fixIts: ["insert type"]), | ||
], | ||
fixedSource: "<#type#>self" |
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.
<#type#>.self
?
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 consume self
as unexpected here. I’m not sure if <#type#>.self
is really any more useful than what we currently produce, so not sure if it’s worth adding a special case for this recovery.
To put it into context, if you write let a: self
, I don’t think that let a: <#type#>.self
is a meaningful recovery strategy. We could suggest wrapping self
in backticks here, but I’m 100% sure that’s not what the developer intended either.
|
||
assertParse( | ||
""" | ||
@derivitave(of: 1️⃣Self.other) |
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.
@derivitave(of: 1️⃣Self.other) | |
@derivative(of: 1️⃣Self.other) |
We weren’t matching the C++ parser’s behavior here. The `self` keyword is not allowed as a type name. `Self` in a nested type refers to a type named `Self` instead of the `Self` keyword.
f75b5fd
to
d171dc5
Compare
…rse` In many of these places, the test case tested the exact same thing if we didn’t pass a custom `parse` function to `assertParsse`. Default to `SourceFileSyntax.parse` because it produces the more natural diagnostics.
@swift-ci Please test |
@swift-ci Please test Windows |
We weren’t matching the C++ parser’s behavior here. The
self
keyword is not allowed as a type name.Self
in a nested type refers to a type namedSelf
instead of theSelf
keyword.