This attribute allows one to provide the "legacy" name of a class for
the purposes of archival (via NSCoding). At the moment, it is only
useful for suppressing the warnings/errors about classes with unstable
archiving names.
The name mangling changed from Swift 3 to Swift 4, and may get slight
tweaks as we lock down ABI stability. Identify and warn about (in
Swift 3) or error about (in Swift 4) the cases where we don't have
obviously-stable name mangling, e.g.,
* private/fileprivate classes (whose mangled names involve the file name)
* nested classes (whose mangled names depend on their enclosing type)
* generic classes (whose mangled names involve the type arguments)
Recent changes to the stdlib resulted in some expressions involving
literals and operators that have both generic and non-generic overloads
to become ambiguous. The ambiguity is due to an old performance hack in
the solver which unfortunately needs to remain in place at the moment to
avoid regressing expression type checker performance.
This commit changes the performance hack a bit in that instead of
stopping visiting the options in a disjunction as soon as we have a
solution involving non-generic operators and come across a constraint
involving generic operators, we instead continue visiting the elements
in the disjunction, but just skip over the generic operators.
Fixes rdar://problem/31695865 and rdar://problem/31698831.
The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
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
When an extension introduces a conformance that already exists, the
type checker will reject the conformance and then ignore it. In cases
where the original conformance is in the same module as the type or
protocol (but the new, redundant conformance is in some other module),
downgrade this error to a warning. This helps with library-evolution
cases where a library omitted a particular conformance for one of its
own types/protocols in a previous version, then introduces it in a new
version.
The specific driver for this is the conformance of String to
Collection, which affects source compatibility. Fixes
rdar://problem/31104415.
We previously used a simple heuristic of visiting the disjunction with
the fewest number of elements in it.
Instead, this commit introduces a new way to select the best disjunction
to explore based on attempting disjunctions based on either how much
information we have about the associated type variables (e.g. how many
of the arguments of a function call in the case of bind overload
disjunctions) or by other criteria that help constraint the search or
split the connected components (e.g. coercions and calls to
initializers).
A key part of the improvement here is allowing the type checker to
attempt bindings of types to type variables when there are still
argument conversion constraints between type variables in the
system. The insight here is if there are no other constraints blocking
an attempt to bind types and we have types to try, we will be able to
test those types against active conformance constraints and potentially
fail much earlier while solving.
Visiting disjunctions in a different order exposed some other problems
with the type checker including a couple cases where map is used that
are now considered ambiguous due to problems in how we are ranking
solutions.
I measured an 11-13% reduction in type checking time for the standard
library using a release build of the compiler.
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.
