Introduce the compiler directive `#_hasSymbol` which will be used to detect whether weakly linked symbols are present at runtime. It is intended for use in combination with `@_weakLinked import` or `-weak-link-at-target`.
```
if #_hasSymbol(foo(_:)) {
foo(42)
}
```
Parsing only; SILGen is coming in a later commit.
Resolves rdar://99342017
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.
Introduce support for parsing declaration attributes that occur within
example:
#if hasAttribute(frozen)
@frozen
#endif
public struct X { ... }
will apply to "frozen" attribute to the struct `X`, but only when the
compiler supports the "frozen" attribute.
Correctly determining whether a particular `#if` block contains
attributes to be associated with the following declaration vs.
starting a new declaration requires arbitrary lookahead. The parser
will ensure that at least one of the branches of the `#if` contains an
attribute, and that none of the branches contains something that does
not fit the attribute grammar, before committing to parsing the `#if`
clause as part of the declaration attributes. This lookahead does
occur at the top level (e.g., in the parsing of top-level declarations
and code), but should only need to scan past the first `#if` line to
the following token in the common case.
Unlike other `#if` when used to wrap statements or declarations, we
make no attempt to record the `#if` not taken anywhere in the AST.
This reflects a change in attitude in the design of the AST, because
we have found that trying to represent this information there (e.g.,
via `IfConfigDecl`) complicates clients while providing little value.
This information is best kept in the syntax tree, only.
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.
Instead of setting the code completion position when parsing the if-statement, which doesn’t create a `CodeCompletionExpr`, parse it as a new top-level expression.
As far as test-cases are concerned, this removes the “RareKeyword” flair from top-level completions in the modified test case. This makes sense IMO.
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.
At the moment, if there is an error in the `switch` statement expression or if the `{` is missing, we return `nullptr` from `parseStmtSwitch`, but we consume tokens while trying to parse the `switch` statement. This causes the AST to not contain any nodes for the tokens that were consumed while trying to parse the `switch` statement.
While this doesn’t cause any issues during compilation (compiling fails anyway so not having the `switch` statement in the AST is not a problem) this causes issues when trying to complete inside an expression that was consumed while trying to parse the `switch` statement but doesn’t have a representation in the AST. The solver-based completion approach can’t find the expression that contains the completion token (because it’s not part of the AST) and thus return empty results.
To fix this, make sure we are always creating a `SwitchStmt` when consuming tokens for it.
Previously, one could always assume that a `SwitchStmt` had a valid `LBraceLoc` and `RBraceLoc`. This is no longer the case because of the recovery. In order to form the `SwitchStmt`’s `SourceRange`, I needed to add a `EndLoc` property to `SwitchStmt` that keeps track of the last token in the `SwitchStmt`. Theoretically we should be able to compute this location by traversing the right brace, case stmts, subject expression, … in reverse order until we find something that’s not missing. But if the `SubjectExpr` is an `ErrorExpr`, representing a missing expression, it might have a source range that points to one after the last token in the statement (this is due to the way the `ErrorExpr` is being constructed), therefore returning an invalid range. So overall I thought it was easier and safer to add another property.
Fixes rdar://76688441 [SR-14490]
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.
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
Introduce availability macros defined by a frontend flag.
This feature makes it possible to set the availability
versions at the moment of compilation instead of having
it hard coded in the sources. It can be used by projects
with a need to change the availability depending on the
compilation context while using the same sources.
The availability macro is defined with the `-define-availability` flag:
swift MyLib.swift -define-availability "_iOS8Aligned:macOS 10.10, iOS 8.0" ..
The macro can be used in code instead of a platform name and version:
@available(_iOS8Aligned, *)
public func foo() {}
rdar://problem/65612624
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.
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`
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
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
