This was happening in the error recovery path when parsing accessors
on a pattern binding declaration that does not bind any variables, eg
let _: Int { 0 }
For example, the completion below would trigger error recovery within the
closure, which we recover from by skipping to the first inner closure's right
brace. The fact that we recovered though, was not recorded. The closure is
treated as still being an error, triggering another recovery after it that
skips over the 'Thing' token, giving a lone closure expression, rather than a
call.
CreateThings {
Thing { point in
print("hello")
point.#^HERE^#
}
Thing { _ in }
}
This isn't an issue for code completion when the outer closure is a regular
closure, but when it's a function builder, invalid elements result in no types
being applied (no valid solutions) and we end up with no completion results.
The fix here is removing the error status from the parser result after the
initial parser recovery.
Expression evaluation in lldb wraps the entire user-written expression
in a new function body, which puts any new declarations written by the
user in local context.
There is a mechanism where declarations can get moved to the top level,
if they're only valid at the top level (imports, extensions etc), or
if the name of the declaration begins with '$'. This mechanism used to
actually add the declaration to the SourceFile's TopLevelDecls list,
which would break ASTScope invariants about source ranges being
monotonically increasing and non-overlapping.
Instead, we use the new 'hoisted' flag to mark the declarations as
hoisted, which leaves them syntactically in their original location
in the AST, but treats them as top level in SILGen and IRGen.
Part of <rdar://problem/53971116>.
When the location given to getLocForStartOfLine was an empty line, it
would actually return the location of the next line rather than the
given location as it should.
If the location given to getLocForEndOfLine was inside a token on a line
that was either empty or contained whitespace, it would skip to the end
of that token and then return the location for the next line. This was
an issue for multiline strings, where the string is a single token but
it's over multiple lines.
This allows the syntax parser library and SwiftSyntax to successfully
parse code using this experimental feature without requiring an API
to pass compiler flags into the parser.
Closurea can become 'async' in one of two ways:
* They can be explicitly marked 'async' prior to the 'in'
* They can be inferred as 'async' if they include 'await' in the body
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
* [Parser] Update 'Confusables.def' file to include confusable and base character names
* [Parser] Add a new utility method to return the names of the confusable and base characters for a given confusable codepoint
* [Parser] Update diagnostic for confusable character during lexing to mention confusable and base character names
* [Sema] If there is just a single confusable character, emit a tailored diagnostic that also mentions the character names
* [Diagnostics] Add new diagnostic messages to the localization file
* [Test] Update confusables test
* [Utils] Update unicode confusables txt file and update script to regenerate confusables def file
* [Parse] Regenerate 'Confusables.def' using updated script
* [Utils] Adjust generate_confusables script based on review feedback
Fix a mistake with name mapping. Updated header comment. Fix a couple of linting issues.
* [Parse] Regenerate 'Confusables.def' file once again after script changes
* [Parse] Add the newline after end of 'getConfusableAndBaseCodepointNames' method
* [Test] Update diagnostic message in 'Syntax/Parser/diags.swift'
Don't insert CodeCompletionExpr at the cursor position in
"conforming method list" or "typecontext" mode. This increase the chance
of successful type checking.
rdar://problem/63781922
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
The parser used to rewrite
if let x: T
into
if let x: T?
This transformation is correct at face value, but relied on being able
to construct TypeReprs with bogus source locations. Instead of having
the parser kick semantic analysis into shape, let's perform this
reinterpretation when we resolve if-let patterns in statement
conditions.
Previously it was backtracking for the duration of the whole property body which was preventing re-use of previously parsed nodes for incremental re-parsing.
Because we were previously performing SIL parsing
during `performSema`, we were relying on the
pipeline being stopped before reaching the SIL
pipeline passes.
However under a lazy evaluation model, we can't
rely on that. Instead, just return an empty
SILModule if we encounter a parsing error.
