* 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 '>'.
Mirrors the fixits provided in ParsePattern for tuples. We now
diagnose multiple extraneous uses of inout and uses of inout attached
to the parameter name and not the type and offer to move them.
When declaring a nominal type:
struct Weak<T> {
weak var value: T
}
The diagnostic might mislead the developer to adding ': class' literally
to the 'T' in the generic parameters for `Weak`:
"'weak' may not be applied to non-class-bound protocol 'T'; consider
adding a class bound"
This is misleading in two ways: 1, 'T' isn't necessarily a protocol
(this patch generalizes that part of the message) and 2, you can't put
`: class` in the generic parameter list for `Weak`. In addition, the
stray class constraint causes diagnostic spew that also hides the issue.
Also provide a fix-it to constrain with 'AnyObject', which is probably
what the devloper means in this case.
rdar://problem/25481209
A function declaration like:
func dog cow() {}
... yields a bunch of noisy diagnostics about expecting certain tokens, like
"expected '(' in argument list of function declaration", or the dreaded
"consecutive statements on a line must be separated by ';'". Instead,
look for a repeated identifier in this position and affirm that the
repeated identifier wasn't expected, suggesting that maybe this was a
single identifier with a break in it.
rdar://problem/25761940
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
When declaring a function like func repeat(){}, the diagnostic is
"expected an identifier" but 'repeat' looks like a reasonable
identifier at first glance, so actually say why it isn't.
rdar://problem/25761380
