-
Notifications
You must be signed in to change notification settings - Fork 400
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
Further naming improvements for syntax node children #1896
Conversation
@swift-ci Please test |
name: "PatternExpr", | ||
name: "Pack", | ||
deprecatedName: "PatternExpr", |
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.
@hborla I renamed the expression in PackExpansionExprSyntax
from patternExpr
to pack
. Does this make sense to you. PatternExpr
didn’t make sense to me because the expression after repeat
isn’t a pattern in the Swift pattern matching sense.
name: "PatternType", | ||
name: "Pack", | ||
deprecatedName: "PatternType", |
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.
@hborla I renamed the underlying type in PackExpansionTypeSyntax
from patternType
to pack
. Does this make sense to you. PatternType
didn’t make sense to me because the expression after repeat
isn’t a pattern in the Swift pattern matching sense and it’s not really a pattern here.
7ca9689
to
c011db2
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
c011db2
to
7f32d45
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
7f32d45
to
a04a35b
Compare
@swift-ci Please test |
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.
Nice improvements in general IMO. I do much prefer "s" over "list". "returnClause.returnType" is amusing too, nice catch.
@@ -1460,7 +1471,8 @@ public let DECL_NODES: [Node] = [ | |||
documentation: "The `#` sign." | |||
), | |||
Child( | |||
name: "Macro", | |||
name: "MacroName", |
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 use Name
for most other nodes, any reason to prefer MacroName
here?
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 use Name
for nodes that declare something (e.g. StructDeclSyntax
), while this node refers to something. And I just thought that name alone here is a little ambiguous because it’s not entirely sure what the name is. I don’t have super strong opinions here though.
name: "Macro", | ||
name: "MacroName", | ||
deprecatedName: "Macro", |
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 as the decl case, ie. MacroName
vs Name
@@ -1398,7 +1411,8 @@ public let EXPR_NODES: [Node] = [ | |||
isOptional: true | |||
), | |||
Child( | |||
name: "PostfixExpression", | |||
name: "BaseExpression", |
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.
Keeping Expression
here on purpose?
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.
Good catch, Base
is better.
) | ||
} | ||
|
||
/// Identifier is a wonderful ambiguous term. Almost always, 'name' or something similar is more expressive |
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.
FWIW I don't see that much difference between name and identifier. Other than name being a little simpler. Sure, in a general sense "identifier" is probably more ambiguous than "name". But in the parser sense not so much. Also all our names are IdentifierToken
🤷.
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.
For me Identifier
in the SwiftSyntax context is an identifier token, ie. technically just a word. And that identifier token can server multiple purposes, refer to a value, name a type, be a function parameter label, …
And wherever we have a clear usage of that identifier token (eg. when it is the name of a nominal type), I think we should name the child by the usage.
) | ||
} | ||
|
||
func testChildrenDontEndWithExprEtc() { |
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.
testChildrenDontEndWithNodeKind
? Doesn't really matter though (and "Syntax" isn't a kind) 😅
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.
Yes, Syntax
isn‘t a kind, children still shouldn’t end with Syntax
😉
a04a35b
to
fcee3e1
Compare
@swift-ci Please test |
@swift-ci Please test |
@swift-ci Please test Windows |
a714bed
to
b9a3830
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
Add a few more syntax child name validation rules and update child names
Token
Identifier
->Name
is usually the better nameIdentifier
-> often it doesn’t provide any additional valueArgs
Expr
,Expression
,Type
etc. -> usually we can just omit these words