SequenceExprSyntax should have odd number elements. Previously 'a as b'
was parsed like:
```
(sequence_expr
(identifier_expr "a"),
(as_expr
'as'
(typeidentifier "b")))
```
So it had even number elements. Now it's parsed
```
(sequence_expr
(identifier_expr "a"),
(unresolved_as_expr 'as')
(type_expr
(typeidentifier "b")))
```
This represents labeled statements as an explicit kind of statement and removes the Labeled trait. Any kind of statement is allowed to be labeled in the tree, but we specifically diagnose the syntax elements that aren't allowed to have labels. This homogenizes the way clients deal with statement labels and also makes parser recovery quite a bit easier in the case where we have a label but no actual statement following it.
When the source code is invalid, this allows us to represent tokens that could not be used to form a valid syntax tree with more fidelity.
This commit does not start using GarbageNodes yet, it just sets everything up for them.
Initializer declarations were missing support for `async`, in part
because they deplicated most of the `FunctionSignature` production.
Instead, use `FunctionSignature` consistently and let the presence of a
result type be a semantic error.
To use _RegexParser from SwiftSyntax.
* Create 'libswiftCompilerModules_SwiftSyntax.a' which is a subset of
'libswiftCompilerModules.a'
* Link 'lib_InternalSwiftSyntaxParser' to
'libswiftCompilerModules_SwiftSyntax.a'
* Factor out swift runtime linking logic in CMake so that dynamic
libraries can link to Swift runtime, in addition to executables
* Link 'lib_InternalSwiftSyntaxParser' to swift runtime
Fixes a SwiftSyntax parsing assertion failure if there is a regex literal at the end of the file. I.e. either a single line regex literal in a file without a trailing newline or a multi-line regex literal.
This does not crash in non-assert builds.
`libInternalSwiftSyntaxParser.dylib` currently doesn’t link against `SwiftExperimentalStringProcessing`, so it can’t use the regex lexing functions defined within. This caused SwiftSyntax to fail if the source code contained regex literals.
Implement a fallback regex lexing function in C++ and use it for SwiftSyntax parsing.
rdar://93580240
Co-authored-by: Rintaro Ishizaki <rishizaki@apple.com>
When recovering from a parser error in an expression, we resumed parsing at a '{'. I assume this was because we wanted to continue inside e.g. an if-body if parsing the condition failed, but it's actually causing more issue because when parsing e.g.
```swift
expr + has - error +
functionTakesClosure {
}
```
we continue parsing at the `{` of the trailing closure, which is a completely garbage location to continue parsing.
The motivating example for this change was (in a result builder)
```swift
Text("\(island.#^COMPLETE^#)")
takeTrailingClosure {}
```
Here `Text(…)` has an error (because it contains a code completion token) and thus we skip `takeTrailingClosure`, effectively parsing
```swift
Text(….) {}
```
which the type checker wasn’t very happy with and thus refused to provide code completion. With this change, we completely drop `takeTrailingClosure {}`. The type checker is a lot happier with that.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
For nested `#if ... #endf` in postfix if-config expression, like:
baseExpr
#if COND1
#if COND2
.member
#endif
#endif
Consider the inner `#if` be a postfix if-config with 'nil' base
expression.
https://bugs.swift.org/browse/SR-14929
Previously, we were always accessing the `DeferredTokenNode`’s `Range`, which is not valid if the token is missing, thus causing an assertion failure when asked for its length.
Fixes rdar://77391988 [SR-14552]
Fixe a couple of bugs in libSyntax parsing found by enabling `-verify-syntax-tree` for `%target-build-swift`:
- Fix parsing of the `actor` contextual keyword in actor decls
- Don't build a libSyntax tree when parsing the availability macro
- The availability macro is not part of the source code and doesn't form a valid Swift file, thus creation of a libSyntax tree is completely pointless and will fail
- Add support for parsing `@_originallyDefinedIn` attributes.
- Add support for parsing `#sourceLocation` in member decl lists
- Add support for effectful properties (throwing/async getters/setters)
- Add support for optional types as the base of a key path (e.g. `\TestOptional2?.something`)
- Allow platform restrictions without a version (e.g. `_iOS13Aligned`)
We were only keeping track of `RawSyntax` node IDs to incrementally transfer a syntax tree via JSON. However, AFAICT the incremental JSON transfer option has been superceeded by `SyntaxParseActions`, which are more efficient.
So, let’s clean up and remove the `RawSyntax` node ID and JSON incremental transfer option.
In places that still need a notion of `RawSyntax` identity (like determining the reused syntax regions), use the `RawSyntax`’s pointer instead of the manually created ID.
In `incr_transfer_round_trip.py` always use the code path that uses the `SyntaxParseActions` and remove the transitional code that was still using the incremental JSON transfer but was never called.
We have finally reached our goal of optimising deferred node creation
for SyntaxTreeCreator. Instead of creating dedicated deferred nodes and
copying the data into a RawSyntax node when recording, we always create
RawSyntax nodes. Recording a deferred node is thus a no-op, since we
have already created a RawSyntax node. Should a deferred node not be
recorded, it stays alive in the SyntaxArena without any reference to it.
While this means, we are leaking some memory for such nodes, most nodes
do get recorded, so the overhead should be fine compared to the
performance benefit.
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.
* [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'
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
