When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
Ensure that we use the correct python to run the python based tools.
This also allows these tools to run on Windows which will not
necessarily associate the python script with an interpreter (python).
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
