Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
This snippet type checks in Swift 4 mode, but not in Swift 3.
It used to work in Swift 3.0, so something broke when we
implemented SE-0110 and redid the Swift 3 mode emulation.
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.
When this was migrated over to the awesome new special representation
of type(of:) the argument coercion didn’t come with it. The missing
load expression caused any l-value run through type(of:) to crash in the
verifier.
The prohibition in Swift 3.0 missed the case where the single-element tuple was wrapped in extra parens as the only argument of a function. We've ripped out parts of the type checker that try to cope with single-element tuples, and it would be risky and bug-prone to try to admit this code, so it's better to fix the ban than to try to accept the code, alas. Fixes SR-3788.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
Swift 3.0 allowed constructing an enum or calling a function-typed
property with multiple arguments even when a single argument of tuple
type was expected. Emulate that in Swift 3 mode by wrapping in an
extra level of parentheses when the situation comes up.
Last vestiges of fallout from SE-0110. Hopefully last, anyway. A nice
follow-up to this commit might be to /warn/ in Swift 3 mode when this
happens.
rdar://problem/30171399
In Swift 3, we had a bug where you could provide argument labels
to a function call taking a single Any parameter, even if the
parameter did not have a label.
This mostly worked (with asserts off!) but in fact it would crash
in SILGen if you were calling an enum case constructor.
Since this 'feature' has been promoted from 'works on accident' to
'still a hack but guarded by Swift 3 mode and exists on purpose',
fix the crash, even though Swift 3 could not compile the code in
question.
Also add a Swift 3 mode check to the earlier SILGen hack, so that
when/if we remove Swift 3 mode it will be obvious that this code is
now dead too.
Swift's language model doesn't guarantee that type metadata will ever really be used, which makes overriding initialize() error-prone and not really any better than manually invoking an initialization function. Warn about this for Swift 3 compatibility and reject attempts to override +initialize in Swift 4.
...instead of just ignoring the errors in certain cases, in service of
source compatibility.
Swift 3.0 wasn't nearly as strict as checking access control for types
because it didn't look at the TypeRepr at all (except to highlight a
particular part of the type in diagnostics). It also looked through
typealiases in certain cases. Approximate this behavior by running the
access checking logic for Types (rather than TypeReprs), and downgrade
access violation errors to warnings when the checks disagree.
Part of rdar://problem/29855782.
In Swift 4 mode, no longer consider e.g. 'nsNumber as Int' or 'nsValue as NSRange' to be valid coercions. This would break compatibility with Swift 3, so in Swift 3 mode, accept the coercion, but *also* accept a checked cast without a warning, and raise a migration warning about the unchecked coercion.
In Swift 3, unqualified lookup would skip static methods
when performing a lookup from instance context.
In Swift 4 mode, if a module method is shadowed by a static
method, you will need to qualify the module method with the
module name.
It would have been nice to isolate the quirk in Sema and
not AST, but unfortunately UnqualifiedLookup only proceeds
to lookup in the module if scope-based lookup failed to find
anything, and I don't want to change that since it risks
introducing performance regressions.
Fixes <rdar://problem/29961715>.
When enumerating requirements, always use the archetype anchors to
express requirements. Unlike "representatives", which are simply there
to maintain the union-find data structure used to track equivalence
classes of potential archetypes, archetype anchors are the
ABI-stable canonical types within a fully-formed generic signature.
The test case churn comes from two places. First, while
representatives are *often* the same as the archetype anchors, they
aren't *always* the same. Where they differ, we'll see a change in
both the printed generic signature and, therefore, it's
mangling.
Additionally, requirement inference now takes much greater
care to make sure that the first types in the requirement follow
archetype anchor ordering, so actual conformance requirements occur in
the requirement list at the archetype anchor---not at the first type
that is equivalent to the anchor---which permits the simplification in
IRGen's emission of polymorphic arguments.
Same as previous, but for availability. Again, it would be great
to get some follow-up work to make these into warnings instead of
just silencing them, but restoring source compatibility is the
first priority.
Rest of rdar://problem/29782505.
Swift 3 just looked at what types we ended up with, not what types
we had to traverse to get there. Preserve this behavior for source
compatibility. (We ought to be able to warn, at least, but for now
getting source compatibility back is most important.)
Part of rdar://problem/29782505.
Like 9fba89bd, typealiases in parameter position were sometimes
canonicalized away in Swift 3.0, leading to the compiler not
diagnosing improper uses of typealiases. These only occurred in "safe"
circumstances where the typealias wouldn't be leaked to clients of a
library (that is, a client would never see a name they wouldn't be
allowed to type), but it was inconsistent with other typealiases
(which were preserved) and did not follow the intended model.
This particular issue comes from typealiases for function types
needing to be marked as non-escaping in the compiler when used in
parameter position, which requires rebuilding the function type. This
lost the original "spelling" of the parameter as using a typealias in
its type, which meant the compiler did not see it. The change in
a32e11a0d to use TypeReprs to check access meant the model was now
correctly enforced, but broke source compatibility for this
"accidental feature".
The fix is to track when a typealias for a function type is being used
in parameter position, and to not check its access in that case.
rdar://problem/29739577
In Swift 3.0.1, argument labels are ignored when calling a function
having a single parameter of 'Any' type. That is, if we have:
func foo(_: Any) {}
Both of the following were accepted in a no-assert build (an assert
build would crash, but the GM builds of Xcode ship with asserts off):
foo(123)
foo(data: 123)
This behavior was fixed by 578e36a7e1,
but unfortunately we have to revert to the old behavior *and* defeat
the assertion when in Swift 3 mode.
Swift 4 mode still has the correct behavior, where the second call
'foo(data: 123)' produces a diagnostic.
Now, I have to pour myself a strong drink to forget this ever happened.
Fixes <rdar://problem/28952837>.
There's a general problem where a SubscriptExpr has an argument
that's a LoadExpr loading a tuple from an lvalue. For some reason
we don't construct the ParenExpr in this case, which confused
CSDiag.
Also, in Swift 3 mode, add a total hack to fudge things in
matchCallArguments() in the case where we erroneously lost
ParenType sugar.
Fix matchTypes() to be more careful about stripping off ParenType
sugar, in order to match the behavior outlined in SE-0110.
Note that the new logic only executes in Swift 4 mode; there's
no functional change here in Swift 3 mode.
This makes a second copy of the tuple_arguments test:
- Compatibility/tuple_arguments is a test for Swift 3, updated to
note differences with Swift 3.
- Constraints/tuple_arguments has been updated for the new Swift 4
mode behavior.
Fixes <rdar://problem/27383557>.
Basically if the underlying type of a typealias was dependent on
generic parameters from context, it wouldn't participate in
accessibility checking.
Turns out people were (accidentally) relying on this behavior, so
add a simulation of it in Swift 3 mode by ignoring such typealiases
entirely.
Fixes <rdar://problem/29549232>.
PR #5857 started rejecting generic requirements that adding
constraints directly to 'Self', which means the requirements would be
unsatisfiable by some models. At the time that commit was merged, we
had thought the compiler crashed on all instances of this problem.
It turns out that, with assertions disabled, these protocols would be
accepted and could be used, so downgrade the error to a 'deprecated'
warning in Swift 3 compatibility mode.
This allows us to run our entire test suite (well, okay, just
invocations of swift/swiftc and swift-ide-test) under Swift 3 mode or
Swift 4 mode, which will be more important as the two modes diverge.
The default is Swift 3 mode for now, which matches the behavior before
this patch (because the master compiler still calls itself 3.0).
Individual tests can still use "-swift-version 3" to override the mode
set by lit, but if an entire test requires Swift 3 or Swift 4, there's
also a new test feature "SWIFT_VERSION=3" or "SWIFT_VERSION=4".
However, if you /do/ need to override or restrict the version, you
should also add a test for the "other" version as well, unless it's
part of the Compatibility suite or otherwise specifically testing
-swift-version-related functionality.
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.
We previously allowed *any* conformance constraint to an
ExpressibleBy*Literal protocol to provide a default type (e.g.,
Int/Double/String/etc.) based on the kind of literal protocol. This
led to weird type inference behavior. Restrict the defaulting to
actual literals---not just conformances to literal protocols---which
is a much more reasonable rule.
Because this is a source-breaking change, only introduce this new
behavior when the Swift version >= 4, maintaining the old behavior in
Swift 3 compatibility mode.
Fixes: https://bugs.swift.org/browse/SR-2843
'P1 & P2.Type' is mistakingly accepted and parsed as (meatatype (composition P1, P2))
in swift3. Now, we parse it as (composition P1, (metatype P2))
For source compatibility, reconstruct it as Swift3.
Also, this solves inconsistent behavior between type and type-expression in Swift3.
typealias T1 = P1 & P2? // was accepted as '(P1 & P2)?'
let T2 = (P1 & P2?).self // was silently accepted as 'P1' in Swift3.0
The recent @escaping on variadic argument closures back-compat fix is
the first Swift 3.0 compatibility behavior that we don't want to carry
forwards indefinitely into the future. To address this, we
version-gate the diagnostic suppression.
Makes it an official compatibility check. Creates new test directory
for compatibility testing. Allow -swift-version 4 so that we can test
it both ways.
