Treat non-optional generic parameters as being more specialized than
optional generic parameters, and penalize any solutions that involve
generic arguments that are themselves Optional.
By doing these things, we can remove the special-cased code for the
two overloads of '??' in the stdlib, instead treating the (T?, T)
overload as better than the (T?, T?) overload except where a user
actually passes an optionally-typed value as the second parameter.
Fixes: rdar://problem/19748710
to be stable.
We currently will stop visiting the elements of a disjunction under
certain circumstances once we have found a solution. The result we get
is inherently dependent on the order in which we determine to visit
the disjunctions themselves (in addition to the elements of the
disjunction).
This change makes the order in which we visit disjunctions
stable. Future commits will create a stable ordering for the elements
of disjunctions. Once we also have that stable ordering in place we
can in theory short circuit more often as part of changing the way in
which we decide what the "best" solution is to a system.
This results in an expression in
validation-test/stdlib/AnyHashable.swift.gyb no longer being able to
typecheck in a reasonable amount of time, so I had to tweak that
expression.
Instead of mixing flags between type-checker and constraint solver, let's
move the ones which are useful in constraint system there. Doing
so allows for `solveForExpression` to be moved from `TypeChecker` to
`ConstraintSystem` which consolidates solver logic.
It also allows to set these flags as part of constraint generation/solving,
which is sometimes important.
Replace the last (and most obscure) use of the poor “use ‘?’ or ‘!’” diagnostic with the
new, more explanatory version that provides separate notes with Fix-Its for coalescing or
force-unwrapping the value.
Finishes rdar://problem/42081852.
Introduce a new fix kind into the constraint solver to cover unwrapping the base
of a member access so we can refer to the a member of the unwrapped base.
Wire this fix kind to the just-added diagnostic that suggests either the
chaining ‘?’ or the force-unwrap ‘!’ via separate, descriptive Fix-Its.
Example:
error: value of optional type 'X?' must be unwrapped to refer to member 'f' of wrapped base type 'X'
let _: Int = x.f()
^
note: chain the optional using '?' to access member 'f' only for non-'nil' base values
let _: Int = x.f()
^
?
note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
let _: Int = x.f()
^
!
Before this, we would sometimes get a Fix-It for just ‘?’ and sometimes get a Fix-It for the
coalescing ‘??’, neither of which is likely to be right.
More work on rdar://problem/42081852.
Revise the heuristic so that it does not differ between Swift
versions, and so that it is always based on the number of scopes we've
opened.
The memory threshold and (very long) timer are also still in place as
well.
This fixes a subtle issue where, during single-expression closure type inference, we would ask for the settability of local variables from the outer function's context, leading us to mistakenly consider them mutable inside single-expression closure contexts. DI would catch some but not all violations of the expected semantics here.
If the user specifies a memory threshold on the command-line, try to
honor that value and consider expressions too complex if we end up
allocating more memory than they specify.
Fixes rdar://problem/40952582 (aka https://bugs.swift.org/browse/SR-7525).
If solver encounters a typealias inside of constrainted extension
make sure to add its requirements to the constraint system, otherwise
it might produce invalid solutions.
Refactor the interface to return a bit vector. Along the way, fix up
the callers and remove some dead usages of the defaults information
that were copied and pasted around Sema.
Number of defaults is a fallback condition if there are no other
differences, but pontential bindings which are literal should always
be ranked lower than anything else because there is a higher chance
that such bindings are wrong because their full set might not have
been resolved yet.
Resolves: rdar://problem/39616039
Currently we have this non-optimal behavior in `contractEdges` where
for every type variable it gathers constraints for its whole equivalence
class before checking if any are "contractable", instead constraints
could be gathered/filtered once which removes a lot of useless work.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Given something like `max(1, 2)` inside a type that conforms to Sequence, this
allows the compiler to consider Swift.max as well as the two methods with that
name on Sequence.
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.
Many (perhaps most?) calls to createTypeVariable explicitly pass 0 for
options. This change just defaults the parameter to 0 and removes all
the explicit 0's in the code.
They can show up when re-typechecking via diag or code-completion and were
only being sanitized out in one place in CSDiag. Moved that logic into
SanitizeExpr.
Resolves rdar://problem/38149042
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
Such overloads are not going to result in viable solutions anyway,
so it makes sense to attempt them only if solver failed to deduce
proper solution.
Helps to improve type-checking performance of operators which have
multiple unavailable overloads for compatibility reasons.
Some of the expressions call into `typeCheckExpressionShallow` while trying to
apply solutions, we need to respect the fact that sub-expressions might be
already properly type-checked while propagating l-value access kind.
Resolves: rdar://problem/38309176
Move all the code specific to dealing with relational constraints out
into a separate function.
I expect to do more refactoring here so this is likely not the final
form for this code - just one step in the direction of breaking things
down into smaller logical pieces.
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
