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.
* Removed `parseConstructorArguments()`, unified with
`parseSingleParameterClause()`.
* Use `parseSingleParameterClause()` from `parseFunctionSignature()`, so
that we can share the recovery code.
* Removed `isFirstParameterClause` parameter from `mapParsedParameters`,
because it's predictable from `paramContext`.
The tentantive parse is used for diagnostic purposes but can cause code-completion to delay the same decl twice.
The range of CodeCompletionExpr was previously character range which invalidated invariants of the AST.
Fixes:
validation-test/IDE/crashers_fixed/084-swift-parser-consumedecl.swift
validation-test/IDE/crashers_fixed/104-swift-gettypeofcompletioncontextexpr.swift
These APIs return SourceLocs, and eventually the Parser should consume
tokens, which now include source trivia such as whitespace and comments,
and package them into a purely syntactic tree. Just a tiny step. NFC.
Store leading a trailing "trivia" around a token, such as whitespace,
comments, doc comments, and escaping backticks. These are syntactically
important for preserving formatting when printing ASTs but don't
semantically affect the program.
Tokens take all trailing trivia up to, but not including, the next
newline. This is important to maintain checks that statements without
semicolon separators start on a new line, among other things.
Trivia are now data attached to the ends of tokens, not tokens
themselves.
Create a new Syntax sublibrary for upcoming immutable, persistent,
thread-safe ASTs, which will contain only the syntactic information
about source structure, as well as for generating new source code, and
structural editing. Proactively move swift::Token into there.
Since this patch is getting a bit large, a token fuzzer which checks
for round-trip equivlence with the workflow:
fuzzer => token stream => file1
=> Lexer => token stream => file 2 => diff(file1, file2)
Will arrive in a subsequent commit.
This patch does not change the grammar.
`InParam` was not used at all.
`StopAtTypeAttributes`
As far as I understand, this option *was* merely for improving diagnostic QoI
for declarations like:
func foo(@typeattr Arg) {}
to fix-it to:
func foo(_: @typeattr Arg) {}
But, this causes the very loudy diagnostics for misplaced type attributes.
For example, on:
func foo(@convention(block) x: () -> CInt) {}
test.swift:1:10: error: expected parameter name followed by ':'
test.swift:1:10: error: expected ',' separator
test.swift:1:10: error: expected ')' in parameter
test.swift:1:9: note: to match this opening '('
test.swift:1:10: error: consecutive statements on a line must be separated by ';'
test.swift:1:11: error: attribute can only be applied to types, not declarations
test.swift:1:21: error: expected declaration
test.swift:1:44: error: statement cannot begin with a closure expression
test.swift:1:44: note: explicitly discard the result of the closure by assigning to '_'
test.swift:1:44: error: braced block of statements is an unused closure
test.swift:1:6: error: expected '{' in body of function declaration
test.swift:1:44: error: expression resolves to an unused function
Now, we emit more accurate diagnostic:
test.swift:1:11: error: attribute can only be applied to types, not declarations
func foo(@convention(block) x: () -> CInt) {}
^
Note that This causes small regression in diagnostics for bare type parameter
like `func foo(@convention(c) () -> CInt) {}`:
Before:
test.swift:1:10: error: unnamed parameters must be written with the empty name '_'
func foo(@convention(block) () -> CInt) {}
^
_:
Now:
test.swift:1:11: error: attribute can only be applied to types, not declarations
func foo(@convention(block) () -> CInt) {}
^
test.swift:1:29: error: unnamed parameters must be written with the empty name '_'
func foo(@convention(block) () -> CInt) {}
^
_:
* [Parse] Remove unused GreaterThanIsOperatorRAII. NFC
Last usage was removed in 68af974227.
* [Parse] Remove unused ArgumentIsParameter flag. NFC
Last usage was removed in 4e4173f2e6
ExprHandle is a relic from a horrible time when expressions made their
way into the type system via default arguments. It's been unnecessary
for a long time, so get rid of it.
When replace something with a punctuator, we often prefer adding spaces around it.
For instance,
func foo(): bar {}
// fix it
func foo() -> bar {}
In this case we want to add a space before '->', but not after that.
With this change, we can simply `fixItReplace(ColonLoc, " -> ")`.
`fixItReplace()` automatically adjust the spaces around it.
This syntax is no longer permitted, but we need to parse it like Swift
2 did in order to produce the fix-it that matches Swift 2 behavior.
rdar://problem/26681485
If an inout parameter has an invalid type, we were unable to
distinguish it from a 'var' parameter, resulting in an invalid
diagnostic.
Fix this by adding a VarDecl::isInOut() flag, instead of
introspecting the type.
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
When declaring a function like func repeat(){}, the diagnostic is
"expected an identifier" but 'repeat' looks like a reasonable
identifier at first glance, so actually say why it isn't.
rdar://problem/25761380
