Add diagnostic for wrong specialize label

[kimdv]

Resolves #1605

[kimdv]

@swift-ci please test

[kimdv]

@swift-ci please test

[ahoppen]

I’d like one more doc comment after reading this with a few days break, otherwise LGTM.

[ahoppen]

@swift-ci Please test

[kimdv]

@ahoppen I did a bit of digging for this issue we breaifly talked about here.
What I can see is, that after calling self.expect(.leftParen) then the current token is e we don't consume it, as e is not a label in @_spacialize(
We then try to find the precedence of the current token. e is an identifier, thus there are none.

Thats why we get this result I think

testMissingClosingParenToAttribute(): failed - Actual output (+) differed from expected output (-):
–@_specialize(e:) <#declaration#>
+@_specialize() <#declaration#>; e

The parser tries to parse the label e and don't know it, so we break out if the loop as you suggested.
So I think it's doing its work correctly (for now)
But it would be more nice if we did consume e as unknown label, and then apply a fixit that suggest to make one if the ones defined in the token set.

[ahoppen]

Ah, what I missed here is that there is no closing ) in the test case. If the input was @_specialize(e) (which is what I thought, I just didn’t check carefully), then expect(.rightParen) would eat the e as unexpected and recover to ). So, I agree that the current recovery is consistent and makes sense for now.

Also, this test case is a little degenerate because it doesn’t have a declaration following the attribute. If you make it a little bit more realistic like

@_specialize(e
func foo() {}

then the fixed source is

@_specialize()e
func foo() {}

Putting the e outside the parentheses makes as much sense as putting it inside, so I think it’s fine and there’s nothing we need to do.

[ahoppen]

One more comment that I forgot last time, otherwise LGTM. Let’s merge this after 2 months 😉

[kimdv]

@swift-ci please test

[kimdv]

@swift-ci please test windows