If all of the solutions in the set have a single fix, which points
to the common anchor, attempt to diagnose the failure as an
ambiguity with a list of candidates and their related problems as notes.
Having richer message like that helps to understand why something is
ambiguous e.g. if there are two overloads, one requires conformance
to some protocol and another has a same-type requirement on some type,
but neither matched exactly, having both candidates in the diagnostic
message with associated errors, instead of simplify pointing to related
declarations, helps tremendously.
Pass constraint system down into offering force unwrap fixits so that we can identify the type of the last member chosen for an optional chain. If there's a chain and the last member's return type isn't optional, then it's cleaner to offer to change that last '?' into a '!' to perform the force, rather than parenthesize the whole expression and force the result.
using it.
It was added to use for selecting the order we visit disjunctions, but
this order turned out to not be great (and I don't think there are
simple variations on the creation order, like reverse order), that
will work well either.
Instead of having to obtain type-checker instance through
constraint system, let's have `emitDiagnostic` do that and
forward all of the argument for easy access.
Aim of this new diagnostic abstraction is to encapsulate each
individual failure into its own class with some shared base.
Good example of this - diagnostics related to generic requirement
failures, where each kind (conformance, same-type etc.) has
some specific logic e.g. diagnostic message but the all share
the same traits like affected declaration/requirement.
Since information comes from `Solution` anyway, it's good to have
that logic localized, but it's also useful for diagnostics based on
fixes attached to solutions.
Any solution which doesn't require source changes should be considered
better than any other solution which does.
Otherwise solutions with fixes are always considered better than
solutions with unavailable overloads, which isn't correct especially
considering that different types of errors are now diagnosed via
forming solutions with fixes.
If fixes are allowed let solver record missing protocol conformance
requirements and assume that `conformsTo` constraint is successfully
solved, this helps to diagnose such errors without involving
heavy-weight expression based diagnostics.
Resolves: rdar://problem/40537858
While inferring avoid associating type variables with closure
parameters, use cache instead and only set types when everything
is properly type-checked, this avoids multiple problems one of
them - leaking type variables outside of constraint system they
belong to.
This makes sure that the diagnostics appear in the stable order
which is closer to what users would expect e.g. evaluation
order, otherwise, because disjunctions are currently attempted
based on their size, ordering of error messages produced by
applying fixes is completely arbitrary.
Let the solver disregard missing argument labels and record correct
ones, so such problem could be diagnosed later on iff there were no
other more serious failures.
* Improve label mismatch callback:
- Split "missing label" callback into 3 - missing, extraneous, incorrect (with typo(s));
- Allow label callbacks to indicate if it's a fatal error or not;
* Improve matching of the variadic parameters;
* Improve matching of the parameters with defaults;
* Try to look for an argument with matching label before fallback to
forced claming (if allowed).
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.
