- `getCalleeLocator`, if given locator ends at `ArgumentAttribute`
strip the last element which makes sure that produced locator
always refers directly to argument-to-parameter conversion.
- `simplifyLocator`, always leave `ArgumentAttribute` in the path
because it's useful for diagnostics.
The parser used to rewrite
if let x: T
into
if let x: T?
This transformation is correct at face value, but relied on being able
to construct TypeReprs with bogus source locations. Instead of having
the parser kick semantic analysis into shape, let's perform this
reinterpretation when we resolve if-let patterns in statement
conditions.
Previously we would always consider an AnyObject
subscript lookup to be ambiguous if there was a
candidate in both a class and protocol, even if
the selectors and types matched. This was due to
the protocol's generic signature preventing the
signatures from being coalesced.
Tweak the logic to strip generic signatures when
comparing for AnyObject lookup, matching what we
do for @objc methods.
Resolves SR-8611.
Resolves rdar://43645564 & rdar://62906344.
Key path dynamic member lookup should be completely transparent
for simplification purposes, it's just a means to get to the current
overload choice.
Resolves: rdar://problem/62989214
Annotate the covered switches with `llvm_unreachable` to avoid the MSVC
warning which does not recognise the covered switches. This allows us
to avoid a spew of warnings.
Now that these are stored in the TypeResolution object itself, and all callers that mutate flags create a new resolution object, this data can be derived from the resolution itself.
Add the appropriate assertions to ensure that the now-redundant options parameters are being kept in sync so they can be retracted.
The eventual goal is to have TypeResolution requestified.
All callers can trivially be refactored to use ModuleDecl::lookupConformance()
instead. Since this was the last flag in ConformanceCheckOptions, we can remove
that, too.
If operator is referenced instead of applied e.g. `arr.sort(by: <)`
ambiguities should be diagnosed as `no exact matches` with attached
notes describing a failure associated with each potential candidate.
Resolves: rdar://problem/62054241
Originally such accessors were only useful for `FailureDiagnostic` but
now since `ConstraintLocator` is anchored with `TypedNode` it makes sense
to make them universally accessible.
Rename `addNewFailingConstraint` to
`recordFailedConstraint`, and call into it
whenever a constraint fails, instead of setting
`failedConstraint`. This ensures that
`-debug-constraints` will always log the constraint
that failed a given scope.
In addition, introduce `retireFailedConstraint`
to cover the common case of retiring a constraint
that just failed.
Pull the entirety of type checking for for-each statement headers (i.e., not the
body) into the constraint system, using the normal SolutionApplicationTarget-based
constraint generation and application facilities. Most of this was already handled
in the constraint solver (although the `where` filtering condition was not), so
this is a smaller change than it looks like.
wrapper original wrapped value expression inside of CSApply.
This prevents type checking the synthesized backing storage initializer
twice - once with the original expression and again with the placeholder.
Type erasure requires a circular construction by its very nature:
@_typeEraser(AnyProto)
protocol Proto { /**/ }
public struct AnyProto : Proto {}
If we eagerly resolve AnyProto, the chain of resolution steps that
deserialization must make goes a little something like this:
Lookup(Proto)
-> Deserialize(@_typeEraser(AnyProto))
-> Lookup(AnyProto)
-> DeserializeInheritedStuff(AnyProto)
-> Lookup(Proto)
This cycle could be broken if the order of incremental inputs was
such that we had already cached the lookup of Proto.
Resolve this cycle in any case by suspending the deserialization of the
type eraser until the point it's demanded by adding
ResolveTypeEraserTypeRequest.
rdar://61270195
Currently `simplifyAppliedOverloads` depends on
the order in which constraints are simplified,
specifically that a lookup constraint for a
function gets simplified before the applicable
function constraint. This happens to work out
just fine today with the order in which we
re-activate constraints, but I'm planning on
changing that order.
This commit changes the logic such that it it's no
longer affected by the order in which constraints
are simplified. We'll now run it when either an
applicable function constraint is added, or a new
bind overload disjunction is added. This also
means we no longer need to run it potentially
multiple times when simplifying the applicable fn.
