Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.
Resolves: rdar://92583588
Make sure that conversions are properly supported when arguments
either is wrapped in an optional type or requires a value-to-optional
promotion because parameter is optional pointer.
We inadvertantly allowed this in the past, so continue to do so when
compiling in Swift 3/4 mode to avoid suddenly breaking existing code.
The diagnostic here is pretty bad, and I've opened issues for that as
well as providing some kind of deprecation warning for this so that
even under Swift 3/4 mode we alert users that this is unsupported.
rdar://problem/39802797
Normally we wouldn't need this because we do not allow overloading by
parameter optionality. In this case, though, we import two Objective-C
methods that end up getting renamed to the same name in Swift, one of
which has a nullability annotation and the other of which doesn't.
Before IUOs were removed from the type system, we would have failed a
subtype test when ranking overloads, but now that subtype test passes
because we're comparing two optionals of the same type. So the change
here is to compare the optionality of the parameters and reject cases
where we are testing whether a plain optional is a subtype of
something declared to be an IUO.
Fixes rdar://problem/38719575.
We can only coerce metatypes covariantly but bridging
always requires an unrelated metatype cast. When
performing member lookup, especially unqualified member
lookup, disregard static members from bridged types entirely.
See SR-5670 and rdar://problem/33830526
We currently have an element in the solution score related to whether we
had a binding or equality constraint involving Any.
Doing this yields some strange results, e.g. if overload resolution
results in a property declared as Any we end up discarding that solution
in favor of solutions that involve other overloads that are not declared
as Any but are also not actually better solutions (e.g. overloads that
are declared as function types).
We really want to retain both solutions in this case and allow the
ranking step of the solver to decide on the better choice.
Fixes rdar://problem/29374163, rdar://problem/29691909.
The former is for debugging, the latter is for detailed presentation to users.
swift -print-ast will continue using printEverything, as will swift-ide-test,
but all other features should use printVerbose.
Swift SVN r20432
