Replace the uglified '__await' keyword with a contextual keyword
'await'. This is more of what we would actually want for the
concurrency model.
When concurrency is enabled, this will be a source-breaking change,
because this is valid Swift code today:
```swift
struct MyFuture<T> {
func await() -> }
func doSomething() {
let result = await()
}
}
```
but the call to `await()` will be parsed as an await expression when
concurrency is enabled. The source break is behind the experimental
concurrency flag, but this way we can see how much of an issue it is
in practice.
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
let value = SomeThing {
...
}
<HERE>
Since Parser parses code-completion token as a part of the expression,
completion failed to suggest 'value'. Also, the type of 'value' is
often '<<error type>>' because of the code completion token.
For now, disable additional trailing closure completion (suggesting
'label: { <#code#> }') on newline positions. Users still get the
compltion on the same line as the closing brace.
rdar://problem/66456159
Similar to `try`, await expressions have no specific semantics of their
own except to indicate that the subexpression contains calls to `async`
functions, which are suspension points. In this design, there can be
multiple such calls within the subexpression of a given `await`.
Note that we currently use the keyword `__await` because `await` in
this position introduces grammatical ambiguities. We'll wait until
later to sort out the specific grammar we want and evaluate
source-compatibility tradeoffs. It's possible that this kind of prefix
operator isn't what we want anyway.
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`
In -swift-version 5 and earlier, #file will continue to be a synonym for #filePath; in a future -swift-version (“Swift 6 mode”), it will become a synonym for #fileID. #file in libraries will be interpreted according to the language mode the library was compiled in, not the language mode its client uses.
Implement this behavior, tied to a frontend flag instead of a language version. We do so by splitting the old `MagicIdentifierLiteralExprKind::File` into two separate cases, `FileIDSpelledAsFile` and `FilePathSpelledAsFile`, and propagating this distinction throughout the AST. This seems cleaner than looking up the setting for the module the declaration belongs to every time we see `File`.
This doesn’t handle module interfaces yet; we’ll take care of those in a separate commit.
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
After trailing closure, we perform "Labeled trailing closure" completion
and fall back to other completion depending on the position.
If the completion happens at a newline position, it used to fallback to
global expression completion, but in type context, we should do override
completion instead.
Also, we didn't use to propagate 'hasCodeCompletion()' status properly.
rdar://problem/64650782
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
For example for:
funcName(base.<HERE>)
Wrap 'base' with 'CodeCompletionExpr' so that type checker can check
'base' independently without preventing the overload choice of 'funcName'.
This increases the chance of successful type checking.
rdar://problem/63965160
At an earlier point, we were doing this check after parsing
the labeled closures, but that never made much sense, since
it's a good diagnostic regardless.
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
Accept trailing closures in following form:
```swift
foo {
<label-1>: { ... }
<label-2>: { ... }
...
<label-N>: { ... }
}
```
Consider each labeled block to be a regular argument to a call or subscript,
so the result of parser looks like this:
```swift
foo(<label-1>: { ... }, ..., <label-N>: { ... })
```
Note that in this example parens surrounding parameter list are implicit
and for the cases when they are given by the user e.g.
```swift
foo(bar) {
<label-1>: { ... }
...
}
```
location of `)` is changed to a location of `}` to make sure that call
"covers" all of the transformed arguments and parser result would look
like this:
```swift
foo(bar,
<label-1>: { ... }
)
```
Resolves: rdar://problem/59203764
Also extend returned object from simplify being an expression to
`TrailingClosure` which has a label, label's source location and
associated closure expression.
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
1) Explicit TypeExpr nodes must be created with a TypeRepr node
2) Implicit TypeExpr nodes must be created with a contextual type
3) The typing rules for implicit TypeExpr simply opens this type
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
