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
* [Parse] Add diagnostic for mixed syntax availability attribute
When parsing a list of availablity specifications in the shorthand syntax, check to see that the next specification is also in shorthand syntax. If the next specification looks like an explicit “deprecated” (or similad) attribute, then emit a specific diagnostic about it to help the developer understand the problem.
https://bugs.swift.org/browse/SR-4231
* [Parse] Add fix-it for single mixed availability syntax
For the scenario that’s described in SR-4231, when there is one shorthard syntax followed by ‘deprecated’ (or similar), then we can guess that the intention was to treat the shorthand as ‘introduced’ so that the two of them work together.
This guess is only made if there is one platform version constrain, that is followed by ‘deprecated’, ‘renamed’, etc. but not ‘introduced’.
https://bugs.swift.org/browse/SR-4231
* Automatic formatting using git-clang-format
* Fix typos in test code and language in comment
Also, consistently names test functions as “deprecated” and "introduced"
* [Parse] Add note to explain the mixed availability syntax fix-it insertion
This change also moves the fix-it from the error to the note.
This adds support for SE-0168, multi-line string literals.
Extend the lexer to recognize the new literals. Test cases added.
There are still areas for future diagnostic improvement, such as fixits and notes as to why a multi-line string literal will be malformed. Multi-line literals are explicitly forbidden inside of string interpolation, though this may be relaxed in the future.
Some messages said 'typealias' and others said 'type alias'.
Change everything to use 'type alias' consistently (except
when it's talking about the keyword itself).
- Separate out a uniquable KeyPathPattern that describes the context-free shape of the key path, with generic parameters and (eventually) subscript index slots factored out.
- Add component kinds for gettable and settable properties.
If the -enable-experimental-subclass-existentials staging flag
is on, resolveType() now allows protocol compositions to contain
class types. It also diagnoses if a composition has more than one
superclass requirement.
Also, change diagnostics that talked about 'protocol composition'
to 'protocol-constrained type'.
Since such types can now contain a superclass constraint, it's not
correct to call them protocol composition.
"Protocol-constrained type" isn't quite accurate either because
'Any' has no protocols, and 'AnyObject' will have no protocols but
a general class constraint; but those are edge cases which won't
come up in these diagnostics.
to correctly handle generalized protocol requirements.
The major missing pieces here are that the conformance search
algorithms in both the AST (type substitution) and IRGen
(witness table reference emission) need to be rewritten to
back-track requirement sources, and the AST needs to actually
represent this stuff in NormalProtocolConformances instead
of just doing ???.
The new generality isn't tested yet; I'm looking into that,
but I wanted to get the abstractions in place first.
The new `@_specialize` attribute has a syntax like this:
```swift
@_specialize(exported: true, kind: full, where K == Int, V == Int)
@_specialize(exported: false, kind: partial, where K: _Trivial64)
func dictFunction<K, V>(dict: Dictionary<K, V>) {
}
```
If `exported` is set, the corresponding specialization would have a public visibility and can be used by clients.
If `exported` is omitted, it's value is assumed to be `false`.
If `kind` is `full` it means a full specialization.
If `kind` is `partial` it means a partial specialization.
If `kind` is omitted, its value is assumed to be `full`.
Add a diagnostic to remove the name of an initializer, deinitializer, or subscript. The identifier token is consumed and skipped to prevent the parser from emitting additional error messages.
Add tests to verify that the name is removed from initializers, deinitializers, and subscripts declared with a name.
Addresses SR-2605.
If you're refactoring a `guard` into an `if`, it's easy to
accidentally end up with invalid code like this in the transition:
```
if condition else {
}
```
The parser rightly complains about the `else`, but has poor recovery
afterward, interpreting the following brace as a closure, which may in
turn lead to other unhelpful errors after:
```
error: expected '{' after 'if' condition
if condition else {
^
error: braced block of statements is an unused closure
if condition else {
^
```
Improve the diagnostics to instead explicitly detect this pattern and
mark it as an error.
