Declarations with special names (e.g. (de-)init and subscript) don't have
identifiers so while trying to diagnose specific problems related to
members check if they have a kind appropriate to the situation.
Resolves: rdar://problem/39514009
Since the functions produce pointers with tightly-scoped lifetimes there's no formal reason these have to only work on `inout` things. Now that arguments can be +0, we can even do this without copying values that we already have at +0.
This disappeared in the rework of IUOs but is needed when we have
multiple potential solutions involving different sets of overloads or
type bindings.
Fixes rdar://problem/37475971.
This function (and getTypeOfMemberReference) deserve a deeper cleanup,
but for the moment lets unblock a compatibility test.
Fixes SR-7098 / rdar://problem/38394645
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
When we perform AnyObject lookup, we can find multiple declarations with
the same signature. When we do so, we pick fairly arbitrarily among them.
However, make sure that we don’t pick an unavailable declaration when
an available declaration is… available.
Fixes rdar://problem/39115471.
Attempt to avoid trying to optimize binary generic disjunctions
when one of the choices has `Any` or `Any?` since it's risky to
assume which one is better without solving.
Resolves: rdar://problem/38625824
The amp_prefix token is currently tolerated in any unary expression
context and then diagnosed later by Sema. This patch changes parsing to
only accept tok::amp_prefix in its allowed position: parameter lists.
This also fixes two "compiler crasher" tests.
We just needed to select the final type based on which branch of the
disjunction successfully type-checked the expression.
Fixes [SR-7208](https://bugs.swift.org/browse/SR-7208)
and rdar://problem/37159360.
If we're willing to tolerate less specific diagnostics, then we can
remove more instances of TVO_CanBindToInOut. After this change, there is
only one client of TVO_CanBindToInOut.
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
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.
Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
If we could find a binding for type variable representing closure result
let's also add implicit `Void` type as another pontential binding to attempt
because there is an implicit conversion from `() -> T` to `() -> Void`
so finding `Void` early is going to help avoid function conversions down
the line.
Resolves: rdar://problem/37790062
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Attempt to use potential bindings inferred for related types variables
discoverable through 'subtype' constraints, this helps to build a
more precise bindings domain for each type variable.
Resolves: rdar://problem/38159133
Currently we always use 'FunctionResult' as a path element when matching
function result types, but closure result type is allowed to be implicitly
converted to Void, which means we need to be careful when to use
'FunctionResult' and 'ClosureResult'.
Resolves: rdar://problem/37790062
We were inserting function conversion expressions that were then
turned into forces of values in cases where we merely referenced
functions, but did not actually call them.
Fixes rdar://problem/37241550.
We were not handling IUO results of @optional protocol methods
properly, sometimes forcing the @optional requirement rather than the
result of the call.
Fixes rdar://problem/37240984.
Fixes a bug in `getPotentialBindings` when the source of the bindings
is 'OptionalObject' constraint and type variable is on the left-hand
side of that constraint, that makes such type variable always have an
optional type since right-hand side of 'OptionalObject' is its 'object'
type.
Resolves: rdar://problem/37508855
This is useful for explicit casts and type expressions, where
type loc and expression types might be different, and allows
constraint solver to avoid setting opened types to expressions
which resolves multiple crashes.
With all else equal prioritize bindings with fewer defaultable types,
which always gets us closer to solution since defaultable bindings
mostly come from the collections and could be checked at the end.
This also makes sure that solver not as aggresive at assigning bindings
to trailing closures and allows solver to consider types which come
from inside the closure.
Resolves: rdar://problem/37290898
