We should let Sema set ParamDecl's specifier always, instead of setting
it in the parser in this odd corner case where we're recovering from
'inout' being written before the parameter name.
Made an utility method 'consumeArgumentLabel', and use it for:
* Labels in tuple type
* Labels in tuple expression
* Argument and parameter names in parameter clause
Variable declarations are declarations led by either 'var' or 'let'. It
can contain multiple pattern bindings as children.
For patterns, this patch only creates syntax nodes for simple identifier
patterns, e.g. 'a = 3'. The rest of the pattern kinds are still left
unknown (UnknownPattern).
This patch also refactors the structure of function signature node so
that closure signature can re-use parts of function signature. For
instance, we group arrow and return type to be "ReturnClause". And we
group parenthesized parameter list to be "ParamClause".
This structure of closure signature also calls for a good way to
represent either-or node in libSyntax APIs, since we've two ways to
specify parameters in closure: one is as regular function parameter and
the other is dot-separated simple names.
This commit teaches parser to parse two libSyntax nodes: FunctionCallArgument and
FunctionCallArgumentList. Along with the change, some libSyntax parsing infrastructure changes
as well: (1) parser doesn't directly insert token into the buffer for libSyntax node creation;
instead, when creating a simple libSyntax node like integer literal expression, parser should indicate the location of the last token in the node; (2) implicit libSyntax nodes like empty
statement list must contain a source location indicating where the implicit nodes should appear
(immediately before the token at the given location).
This patch allows Parser to generate a refined token stream to satisfy tooling's need. For syntax coloring, token stream from lexer is insufficient because (1) we have contextual keywords like get and set; (2) we may allow keywords to be used as argument labels and names; and (3) we need to split tokens like "==<". In this patch, these refinements are directly fulfilled through parsing without additional heuristics. The refined token vector is optionally saved in SourceFile instance.
Using these in declaration position has been deprecated and
removed in Swift 3. These attributes were not being parsed and
contained deadweight diagnostics that should have been moved
when these attributes became type attributes.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
Add a diagnostic to remove the name of an initializer, deinitializer, or subscript. The identifier token is consumed and skipped to prevent the parser from emitting additional error messages.
Add tests to verify that the name is removed from initializers, deinitializers, and subscripts declared with a name.
Crashers fixed are minor logic errors:
Patterns: Crash occurred when requesting the range of a created
Pattern. Validity of the range should be checked before returning it
to keep the entire range valid or invalid but never both.
ParseExpr/ParsePattern: The same fixes as the ones provided in #6319
CSDiag: The generic visitor needn’t look through TypeVarTypes either.
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
The crashes fixed appeared at first to be related to IfConfigStmt
parsing, but are in reality symptoms of being too lax in what we accept
when parsing of sub-expressions fail.
Optional type annotation parsing used to propagate failures before it
was patched to ‘recover’ with an AnyPattern. Instead, we’ll just hit
the error path for parsing in the main expressions because what is here
now isn’t a reasonable thing to return.
#selector parsing assumed that the current token it was at after
consuming up to a right-brace wasn’t bogus. Instead, if we’ve got
here, we may as well just return a loc we know is valid: PreviousLoc.
