We don't need special completion logic for things like `#file` and
`#line` now that they are declared in the standard library. Drop it
and update tests.
And adjust contextual parameter modifier parsing in general to be more
properly contextual, so we don't have to reserve `__shared` or `__owned`,
or their successor spellings, as argument labels anymore.
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
* Update DAK_Available name to match @available keyword
Update expected errors for @available attribute tests
* Update available attribute keyword name in DeclAttrKeyword documentation comment
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.
The diagnostic is now a warning and the new message alerts the user that
though it is valid to have let and var as argument label names,
they are interpreted as argument labels, not keywords.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
We had two slightly different codepaths to diagnose ': class'
in an inheritance clause where it is not supported.
For generic parameters, we would fix the 'class' to 'AnyObject',
but for associated types we didn't do this. Perform the fix in
all cases where it makes sense and remove one of the two
diagnostics.
This also removes some dead code, where an early assert() ensures that
'strong' is never passed into the function, but then the function later
tries to handle 'strong'.
Finally, use a switch statement for future proofing.
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
This introduces a few unfortunate things because the syntax is awkward.
In particular, the period and following token in \.[a], \.? and \.! are
token sequences that don't appear anywhere else in Swift, and so need
special handling. This is somewhat compounded by \foo.bar.baz possibly
being \(foo).bar.baz or \(foo.bar).baz (parens around the type), and,
furthermore, needing to distinguish \Foo?.bar from \Foo.?bar.
rdar://problem/31724243
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
We used to drop the entire generic parameter list if one of the
entries failed to parse. This caused a problem where the generic
parameters were still available for name lookup, so they had
to be special-cased since there's no generic environment set up
in this case.
Now, keep the parts of the generic parameter list around that
parsed successfully.
When I first made the change, almost a hundred crashers regressed;
now all the underlying issues have been fixed.
The result is that in addition to removing a crappy hack we get
some more mileage out of the compiler_crashers, because stuff like
this now builds a generic environment:
class S<T{...}
If we found any error in a list, in most cases, we cannot expect that the
following tokens could construct a valid element. Skip them, instead of trying
to parse them as the next element. This significally reduces bogus diagnostics.
Bailout if seeing tok::eof or token that can never start a element, after
parsing an element. This silences superfluous "expected ',' separator" error,
or misleading expected declaration error. What we should emit is
"expected ')' in expression list, or "expected '}' in struct".
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
