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
For instance:
--
let globalVar = {
func something(arg: Int) -> Int {
#^HERE^#
}
return something(12)
}()
--
We want to consider this as a top-level completion, not a function body
completion.
rdar://problem/60838686
We were always dropping the error status when returning from parseExprImpl. We
were also incorrectly keeping error status after recovering by finding the
right close token in parseList. This change fixes both, and also updates a few
callers of parseList that assumed when they reported a failure parsing an
element the list as a whole would get error status, which isn't true due to
recovery.
This restructures the indentation logic around producing a single IndentContext
for the line being indented. An IndentContext has:
- a ContextLoc, which points to a source location to indent relative to,
- a Kind, indicating whether we should align with that location exactly, or
with the start of the content on its containing line, and
- an IndentLevel with the relative number of levels to indent by.
It also improves the handling of:
- chained and nested parens, braces, square brackets and angle brackets, and
how those interact with the exact alignment of parameters, call arguments,
and tuple, array and dictionary elements.
- Indenting to the correct level after an incomplete expression, statement or
decl.
Resolves:
rdar://problem/59135010
rdar://problem/25519439
rdar://problem/50137394
rdar://problem/48410444
rdar://problem/48643521
rdar://problem/42171947
rdar://problem/40130724
rdar://problem/41405163
rdar://problem/39367027
rdar://problem/36332430
rdar://problem/34464828
rdar://problem/33113738
rdar://problem/32314354
rdar://problem/30106520
rdar://problem/29773848
rdar://problem/27301544
rdar://problem/27776466
rdar://problem/27230819
rdar://problem/25490868
rdar://problem/23482354
rdar://problem/20193017
rdar://problem/47117735
rdar://problem/55950781
rdar://problem/55939440
rdar://problem/53247352
rdar://problem/54326612
rdar://problem/53131527
rdar://problem/48399673
rdar://problem/51361639
rdar://problem/58285950
rdar://problem/58286076
rdar://problem/53828204
rdar://problem/58286182
rdar://problem/58504167
rdar://problem/58286327
rdar://problem/53828026
rdar://problem/57623821
rdar://problem/56965360
rdar://problem/54470937
rdar://problem/55580761
rdar://problem/46928002
rdar://problem/35807378
rdar://problem/39397252
rdar://problem/26692035
rdar://problem/33760223
rdar://problem/48934744
rdar://problem/43315903
rdar://problem/24630624
parseClosureSignatureIfPresent.
Otherwise, closure parameters that were parsed as "potentially destructured"
will fail constraint generation, even after the parser has decided
they are not destructured.
* Stage in #filePath
To give users of #file time to transition, we are first adding #filePath without changing #file’s behavior. This commit makes that change.
Fixes <rdar://problem/58586626>.
* Correct swiftinterface test line
