- 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.
Another oddly-named utility function with poorly-defined behavior.
It returned true for archetypes, generic parameters, existential
types, and metatypes of existential types.
However, it would return false for dependent member types, or
metatypes of archetypes, and so on.
All the callers were doing something bad to begin with, so
changing them over to more precise predicates improved the code.
In particular, this simplifies substitution construction in
the SIL parser, and makes it stricter, which turned up a couple
of mistakes in the SIL tests where we were doing stuff with
non-conforming types.
Use a syntax that declares the layout's generic parameters and fields,
followed by the generic arguments to apply to the layout:
{ var Int, let String } // A concrete box layout with a mutable Int
// and immutable String field
<T, U> { var T, let U } <Int, String> // A generic box layout,
// applied to Int and String
// arguments
When in Swift 3 Compatibility Mode we now acceptable a standalone
'$' as an identifier. In all other cases this is now disallowed
and must be surrounded by backticks.
This is a NFC change, since verification still will be behind the flag. But this
will allow me to move copy_value, destroy_value in front of the
EnableSILOwnership flag and verify via SILGen that we are always using those
instructions.
rdar://28851920
