Implements SE-0460 -- the non-underscored version of @specialized.
It allows to specify "internal" (not abi affecting) specializations.
rdar://150033316
The `@differentiable` and `@derivative` attributes need a parent pointer. Move the code to populate it from Parser to AST so it can be more easily shared between the parsers.
Done in preparation for similar code to be added for `@abi`.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
There are sometimes parsing stuations where we don't want to
emit a parsing error, because of feature guarding. For
example, if a Feature involves new syntax for a type, we
must be able to parse both the true and false sides of an
ifdef guarding that new syntax based on a Feature flag.
Cursor info only cares about the `doneParsing` callback and not about all the `complete` functions that are now defined in `CodeCompletionCallbacks`. To make the design clearer, split `IDEInspectionCallbacks`.
rdar://105120332
If the first type has a code completion token, don't record a same type constraint because otherwise if we have
```swift
K.#^COMPLETE^# == Foo
```
we parse this as
```
K == Foo
```
and thus simplify `K` to `Foo`. But we didn't want to state that `K` is `Foo` but that `K` has a member of type `Foo`.
rdar://77458518
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.
Also, store the end location of the where clause explicitly, so that
we can recover it even if there are no requirements.
This fixes one of the failing tests when parser lookup is disabled in
swift-ide-test by ensuring that the source range of the function
extends to the end of the 'where' clause, even though the 'where'
clause has a code completion token in it.
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.
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.
