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.
It used to crash for:
Attribute without its name (e.g. Foo<@>)
Missing name with attributes (e.g. Foo<@available(*, unavailable)>
- Synthesize identifier token so that the SyntaxParsingContext can
successfully construct the Attribute syntax.
- Don't throw away the parsed attributes if the parameter name is
missing. Instead, construct GenericParamater syntax anyway, and handle
it in ASTGen.
For the intermediate lookup table of the parsed decl attributes, use
location the first token of the attributes instead of the start location
of the *parsed* attribute list because some attributes can be ignored
during the parsing.
rdar://problem/55952739
Make sure StructureMarkerRAII checks structure nesting level on all paths. Previously swift crashed with no diagnostic on deeply nested '('. Now we print an error when more than 256 parens deep, just as we always have for '['.
fixes SR-4866
