Originally such accessors were only useful for `FailureDiagnostic` but
now since `ConstraintLocator` is anchored with `TypedNode` it makes sense
to make them universally accessible.
In preparation to anchor `ConstraintLocator` from `TypedNode`
let's refactor diagnostics (which is the biggest user of locators)
to support `TypedNode` instead of `Expr *`.
Split `emitDiagnostic` into `emitDiagnostic` and `emitDiagnosticAt`.
Refactor existing diagnostics to use new methods and avoid passing
location when possible.
Some of the diagnostics have special rules about anchor location,
let's make `getAnchor` virtual and allow sub-class to override
default implementation.
Previously we could allow some invalid coercions to
sneak past Sema. In most cases these would either
cause crashes later down the pipeline or
miscompiles. However, for coercions between
collections, we emitted somewhat reasonable code
that performed a force cast.
This commit aims to preserve compatibility with
those collection coercions that previously
compiled, and emits a warning telling the user to
use either 'as?' or 'as!' instead.
New name is more consistent with existing `getOverloadChoiceIfAvailable`
and allows us to clean up a couple of places where `getCalleeLocator` was
used directly before.
* [CSDiagnostics] Handle arg to param generic when locator points to ConstraintLocator::GenericArgument
* [test] Add SR-12242 test case
* [CSDiagnostics] Handle arg to param on Generic mismatch as a fallback diagnostic
* [CSDiagnostics] Make assign diagnostics in GenericMismatchFailure handle more cases
* [test] Adding test cases for assign expr in GenericMismatch diagnostics
* [CSDiagnostics] Improving inout to pointer argument conversions with optionals diagnostics
Type on the right-hand side of the element conversion/pattern match
should be allowed to have holes to be able to diagnose failures with
structurally incompatible types.
Resolves: rdar://problem/60832876
It's allowed to convert a single statement closure from `(...) -> T` to `(...) -> Void`
_only_ if there is no explicit `return` in the body.
Resolves: [SR-12277](https://bugs.swift.org/browse/SR-12277)
Resolves: rdar://problem/52204414
This helps to avoid allocating new type variables (which shouldn't be done regardless)
to store parameter indices when `missing arguments` diagnostic is used by other diagnostics.
Make diagnostics stateless by providing them with a solution
instead of applying a solution back to constraint system and
using constraint system. Latter doesn't work well when there
is an ambiguity and multiple solutions are available instead
of one.
If mismatch detected by `repairFailures` is related to a complex
wrapped value of optional type formed from optional-to-optional
or value-to-optional conversion let's not try to fix it directly
but let `simplifyRestrictedConstraintImpl` record a top-level fix
for more context.
Resolves: rdar://problem/59703585
It detends on a situation whether try? would get a type inferred
so the mismatch is against a contextual type, or contextual type
would be used as a type of `try?` and fail comparsion with inner
expression type. In either case the mismatch is contextual.
This is something I noticed by inspection while working on
<https://bugs.swift.org/browse/SR-75>.
Inside a static method, 'self' is a metatype value, so
'self.instanceMethod' produces an unbound reference of type
(Self) -> (Args...) -> Results.
You might guess that 'super.instanceMethod' can similarly
be used to produce an unbound method reference that calls
the superclass method given any 'self' value, but unfortunately
it doesn't work.
Instead, 'super.instanceMethod' would produce the same
result as 'self.instanceMethod'. Maybe we can implement this
later, but for now, let's just diagnose the problem.
Note that partially-applied method references with 'super.'
-- namely, 'self.staticMethod' inside a static context, or
'self.instanceMethod' inside an instance context, continue
to work as before.
They have the type (Args...) -> Result; since the self value
has already been applied we don't hit the representational
issue.
