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.
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.
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
