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.
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.
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.
Diagnose an attempt to reference a top-level name shadowed by
a local member e.g.
```swift
extension Sequence {
func test() -> Int {
return max(1, 2)
}
}
```
Here `min` refers to a global function `min<T>(_: T, _: T)` in `Swift`
module and can only be accessed by adding `Swift.` to it, because `Sequence`
has a member named `min` which accepts a single argument.
When requesting information about the contextual type of a constraint
system, do so using a given expression rather than treating it like
the global state that it is.
This is useful in some situations where access to type variable(s)
helps to diagnose the problem properly e.g. if it's a conversion
to generic parameter.
