Implement exhaustiveness checking in Sema with rich error messages. The
algorithm used is a variant of the one described in Fengyun Liu's paper
"A Generic Algorithm for Checking Exhaustivity of Pattern Matching"
published in the EPFL conference, and Luc Maranget's seminal paper
"Warnings for Pattern Matching"
The Space Engine views pattern matching as a problem of projecting the
scrutinee of a pattern-match into a "Space", then iteratively
constructing a Space from the cases. Taking the difference of this
master space and the covered spaces yields the "holes" left over or
reveals a completely covered space.
The algorithm also extends trivially to redundancy checks in patterns,
but that check is already implemented in SILGen and this algorithm does
not improve upon it.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
Introduce a warning about redeclaring the associated types from an
inherited protocol in the protocol being checked:
* If the new declaration is an associated type, note that the
declaration could be replaced by requirements in the protocol's
where clause.
* If the new declaration is a typealias, note that it could be
replaced by a same-type constraint in the protocol's where clause.
In an extension of a nested type, the extended type must be
fully qualified.
Also clean up the diagnostic logic a little bit and centralize
it in diagnoseUnknownType().
Fixes <https://bugs.swift.org/browse/SR-4379>.
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).
@IBInspectable and @GKInspectable both work via the Objective-C
runtime. SE-0160 made them imply @objc, but doing so made it an error
to define an @IBInspectable or @GKInspectable property with a type
that could not be expressed in Objective-C. The attribute is useless,
but this broke Swift 3 code.
So, downgrade the error to a warning in Swift 3 compatibility mode,
with a Fix-It to remove the useless attribute. It remains an error in
Swift 4.
Fixes rdar://problem/31408971.
Track the types we've seen instead of the type declarations we've
passed through, which eliminates some holes relating to generic types.
Detect infinite expansions by imposing an arbitrary limit.
Fixes rdar://30355804
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.
That is, a Swift 3 target imported into a Swift 4 context or vice
versa. This requires serializing the compatibility mode explicitly,
instead of including it in the textual version string that's only
for debugging.
TODO:
- Select the KeyPath subclass corresponding to the write capability of the key path components
- Figure out an issue with unresolved solutions being chosen with contextually-typed keypaths
- Diagnostic QoI
Warn about cases where a storage declaration (property or subscript)
has an accessor with an explicit @objc, but for which the storage
declaration itself is only @objc due to deprecated @objc inference.
Overriding of members introduced in class extensions depends on the
presence of an Objective-C entrypoint. When we override such a
member---which used the deprecated @objc inference rule and occurs in
a class extension, where non-@objc methods currently cannot be
overridden---warn about the use of explicit @objc.
Split the warning into two warnings, because we want different Fix-It behavior.
* For the ‘dynamic’ warning, drop the “in Swift 4” part and keep the @objc Fix-It on the main warning. This is always auto-applyable.
* For the inferred-for-members-of-Objective-C-derived-classes warning, drop the “in Swift 4” part. More importantly, split off two notes: one with the @objc Fix-It (Swift 3 behavior) and one with the @nonobjc Fix-It (Swift 4 behavior). This makes it clearer that there is a choice, and neither is “obviously” correct.
When in Swift 3 compatibility mode without
`-warn-swift3-objc-inference`, warn on the *uses* of declarations that
depend on the Objective-C runtime that became `@objc` due to the
deprecated inference rule. This far more directly captures important
uses of the deprecated Objective-C entrypoints. We diagnose:
* `#selector` expressions that refer to one of these `@objc` members
* `#keyPath` expressions that refer to one of these `@objc` members
* Dynamic lookup (i.e., member access via `AnyObject`) that refers to
one of these `@objc` members.
Introduce an opt-in warning (enabled by the frontend option
-warn-swift3-objc-inference) for each declaration for which @objc is
inferred based on Swift 3 rules that no longer apply after SE-0160.
Rather than the nebulous “do not diagnose”, separate out the two reasons for a non-diagnosed @objc: it’s a member of an Objective-C-derived subclass or it’s an accessor for a property.
Diagnose redundant same-type constraints using most of the same
machinery for diagnosing other redundant constraints. However,
same-type constraints are particularly interesting because
redundancies can be spelled in a number of different ways. Address
this using the connected components of the subgraph involving only
derived requirements (which is already used for the minimized generic
signature). Then, separate all of the non-derived requirements into
the intracomponent requirements and intercomponent requirements:
* All of the intracomponent requirements are redundant by definition,
because the components are defined by derived constraints.
* For the intercomponent requirements, form a spanning tree among the
various components and diagnose as redundant any edges that do not
extend the spanning tree.
As we've done with all of the other kinds of constraints, keep track
of all of the layout constraints on the equivalence class. Use the
normal mechanism to diagnose conflicts between different layout
constraints, warn about duplicate layout constraints, etc.
The variable_never_used fixit transforms into invalid code in the case of two-stage let initialization. I introduced a new diagnostic that does not fixit and suggests removing the value.
Move the storage for the protocols to which a particular potential
archetype conforms into EquivalenceClass, so that it is more easily
shared. More importantly, keep track of *all* of the constraint
sources that produced a particular conformance requirement, so we can
revisit them later, which provides a number of improvements:
* We can drop self-derived requirements at the end, once we've
established all of the equivalence classes
* We diagnose redundant conformance requirements, e.g., "T: Sequence"
is redundant if "T: Collection" is already specified.
* We can choose the best path when forming the conformance access
path.
