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.
Expression evaluation in lldb wraps the entire user-written expression
in a new function body, which puts any new declarations written by the
user in local context.
There is a mechanism where declarations can get moved to the top level,
if they're only valid at the top level (imports, extensions etc), or
if the name of the declaration begins with '$'. This mechanism used to
actually add the declaration to the SourceFile's TopLevelDecls list,
which would break ASTScope invariants about source ranges being
monotonically increasing and non-overlapping.
Instead, we use the new 'hoisted' flag to mark the declarations as
hoisted, which leaves them syntactically in their original location
in the AST, but treats them as top level in SILGen and IRGen.
Part of <rdar://problem/53971116>.
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
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`
If a code completion happens inside an attribute (or in the decl), we
should not insert parsed decls to the AST in the first pass.
rdar://problem/65898101
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.
* initial changes
* Add tests, undo unnecessary changes.
* Fixing up computed properties accessors and adding tests for getters.
* Adding nested type testcase
* Fixing error message for when accessor is referenced but not acutally found.
* Cleanup.
- Improve diagnostic message.
- Clean up code and tests.
- Delete unrelated nested type `@derivative` attribute tests.
* Temporarily disable class subscript setter derivative registration test.
Blocked by SR-13096.
* Adding libsyntax integration and fixing up an error message.
* Added a helper function for checking if the next token is an accessor label.
* Update utils/gyb_syntax_support/AttributeNodes.py
Co-authored-by: Dan Zheng <danielzheng@google.com>
* Update lib/Parse/ParseDecl.cpp
Co-authored-by: Dan Zheng <danielzheng@google.com>
* Add end-to-end derivative registration tests.
* NFC: run `git clang-format`.
* NFC: clean up formatting.
Re-apply `git clang-format`.
* Clarify parsing ambiguity FIXME comments.
* Adding couple of more testcases and fixing up error message for when accessor is not found on functions resolved.
* Update lib/Sema/TypeCheckAttr.cpp
Co-authored-by: Dan Zheng <danielzheng@google.com>
Co-authored-by: Dan Zheng <danielzheng@google.com>
A previous commit inadvertently changed the
logic such that the member hash of an extension
body would be set to a partial interface hash.
Luckily this shouldn't have caused any behavioural
change as the interface hash itself would have
been left unaffected.
This commit makes sure we preserve the original
behaviour where if we don't have the body tokens
hashed separately, we give the body hash a default
constructed MD5.
Noticed by inspection.
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Previously it was backtracking for the duration of the whole property body which was preventing re-use of previously parsed nodes for incremental re-parsing.
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
Because we were previously performing SIL parsing
during `performSema`, we were relying on the
pipeline being stopped before reaching the SIL
pipeline passes.
However under a lazy evaluation model, we can't
rely on that. Instead, just return an empty
SILModule if we encounter a parsing error.
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.
Store an array of Located<Identifier> instead of
an array of Identifiers and SourceLocs on
OperatorDecl. This allows us to cleanup
OperatorPrecedenceGroupRequest a little.
There doesn't seem to be any reason to delay this
diagnostic until after type-checking has finished
any more, so run it along with the rest of
attribute checking.
If there's expected signature after the code completion.
For example:
func <HERE>(arg: Int) {}
This is clearly modifying the function name. We should not perform any
completion including override completion.
rdar://problem/58378950
This meant we weren't producing sema diagnostics for the case, and it didn’t
get full syntactic/semantic highlighting or indentation.
enum CasesWithMissingElement {
case a(Int, String),
case b(Int, String),
}
Resolves rdar://problem/61476844
