Typing `func foo() await {` is something that folks do from time-to-time.
The old error message was unintuitive and suggested adding a semicolon
between the parenthesis and the await, then proceeded to complain about
the opening brace. This wasn't very clear about what the error actually
was.
Pulling this in line with `try`, `throw`, and `throws`, this patch
suggests replacing `await` with `async` when in the function effect
position, and provides a nice fix-it.
Previously, when we reached the maximum nesting level, we changed the current token’s kind to an EOF token. A lot of places in the parser are not set up to expect this token change. The intended workaround was to check whether pushing a structure marker failed (which would change the token kind) and bail out parsing if this happened. This was fragile and caused assertion failures in assert builds.
Instead of changing the current token’s kind, and failing to push the structure marker, let the lexer know that it should cut off lexing, essentially making the input buffer stop at the current position. The parser will continue to consume its current token (`Parser.Tok`) and the next token that’s already lexed in the lexer (`Lexer.NextToken`) before reaching the emulated EOF token. Thus two more tokens are parsed than before, but that shouldn’t make much of a difference.
Split up the expr list parsing members such that
there are separate entry points for tuple and
argument list parsing, and start using the argument
list parsing member for call and subscripts.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
We weren’t setting the code completion token status correctly when parsing patterns with code completion tokens.
Because of this, in the added test case, the `searchSubject` gets added as a member of `Foo` twice - once in the first pass and once in the second pass, causing an assertion failure.
Fixes rdar://80575116 [SR-14687]
With the introduction of `isolated` as
a type modifier for actor types, the
parsing of a parameter regressed such
that `isolated` was no longer accepted
as an ordinary argument label. This patch
fixes that and adds a little lookahead
utility to clean-up the code that
disambiguates the uses of `isolated`
as either a label or a type modifier.
Resolves rdar://80300022
- Allow named opaque types in typed patterns and subscripts
- Fix inheritance clause printing for `GenericParamList`
- clang-format changes from previous commit on this branch
In order to put constraints on opaque types in function returns, we want to
support naming them like 'func f() -> <T> T { }'. This commit parses that
syntax into the new `OpaqueReturnParameteriedTypeRepr`. This is hidden behind
the new flag --enable-experimental-opaque-return-types.
The parsing of Swift 1.0 beta-1 array syntax (e.g., `Int [something]`)
was preventing closures with both a custom attribute (e.g.,
`@MainActor) and a capture list from parsing correctly. Don't parse
that syntax within custom attributes.
Fixes rdar://77303587.
With isolated parameters being part of a function's type, check to
ensure that isolated and non-isolated parameters aren't incorrectly
matched. Specifically, it is okay to add `isolated` to a parameter
when there is a subtyping relationship, but not remove it:
```swift
actor A { }
func f(_: isolated A) { }
func g(_: A) { }
func test() {
let _: (isolated A) -> Void = g // okay to add 'isolated'
let _: (A) -> Void = f // error when removing 'isolated'
}
```
The notion of "actor-isolated" currently exists at the declaration level.
For functions, it is going to be captured in the function type itself,
where 'self' is declared to be 'isolated'. Model isolation both
ways: the 'self' of a method that is isolated to an actor instance
will be 'isolated' as well.
We are still using declaration-based checking of actor isolation.
However, by mirroring this information we can move more incrementally
over to doing checking based on 'isolated' parameters.
We support a special DefaultArgumentKind::NilLiteral, but it was only
used for synthesized and imported default arguments as well.
Let's also use it for parsed default arguments that are exactly 'nil',
so that rethrows checking can special-case them.
From my point of view, a type that contains a code completion token can still be parsed as a type and as such, `canParseType` should return `true` for e.g. `#^COMPLETE^#` or `SomeType.#^COMPLETE^#`.
Changing this fixes an issue that caused no type completions to be shown inside a enum case decl.
Fixes rdar://71984715
For backtracking scopes that are never cancelled, we can completely disable the SyntaxParsingContext, avoiding the creation of deferred nodes which will never get recorded.
By now ParsedRawSyntaxNode does not have any knowledge about deferred
node data anymore, which frees up SyntaxParseActions (and, in
particular its sublass SyntaxTreeCreator) to perform optimisations to
more efficiently create and record deferred nodes.
Always parse `async` and `await`, allowing the definition and use of
asynchronous functions without the "experimental concurrency" flag.
Note that, at present, use of asynchronous functions requires one to
explicitly import or link against the `_Concurrency` library. We'll
sort this out in a follow-up change.
Tracked by rdar://73455330.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
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.
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.
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`
