Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
The current implementation of the check accounts only for the overload
choices present in the initial lookup but for some situations, like
bridged or optional base types, `performMemberLookup` uses a secondary
lookup as well, results of which are ignored.
Let's fold the check into `addChoice` instead and set the the flag there
to make sure that all of the choices are considered.
Resolves: rdar://143586718
If result of `CGFloat` -> `Double` conversion is injected into an optional
it should be ranked based on depth just like when locator is fully simplified.
For example:
```swift
func test(v: CGFloat?) {
_ = v ?? 2.0 / 3.0
}
```
In this expression division should be performed on `Double` and result
narrowed down (based on the rule that narrowing conversion should always
be delayed) but `Double` -> `CGFloat?` was given an incorrect score and
instead of picking `?? (_: T?, _: T) -> T` overload, the solver would
use `?? (_: T?, _: T?) -> T?`.
(cherry picked from commit cb876cbd9e)
Follow-up for https://github.com/swiftlang/swift/pull/82326.
The optional injection is only viable is the wrapped type is
not yet resolved, otherwise it's safe to wrap the optional.
We need to be very careful while matching types to test whether a
fix is applicable or not to avoid adding extraneous fixes and failing
the path early. This is a temporary workaround, the real fix would
be to let `matchTypes` to propagate `TMF_ApplyingFixes` down.
Resolves: rdar://154010220
Resolves: https://github.com/swiftlang/swift/issues/82397
If we have a tuple with unresolved pack expansion on one side
and an optional type on the other, prevent `matchTypes` from
wrapping optional into a one-element tuple because the matching
should be handled as part of the optional injection.
Resolves: rdar://152940244
Package the flag into `performanceHacksEnabled()` method on
`ConstraintSystem` and start using it to wrap all of the hacks
in constraint generator and the solver.
Escaping solver-allocated types into a nested allocation arena is
problematic since we can e.g lazily compute the `ContextSubMap` for a
`NominalOrBoundGenericNominalType`, which is then destroyed when we
exit the nested arena. Ensure we don't pass any types with type
variables or placeholders to `typesSatisfyConstraint`.
rdar://152763265
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
- Mismatch in tuple element position should reference whole tuple
with a note for mismatch position;
- Situations where optional object type is not a class but matched
against `AnyObject` have a tailored fix.
Attempting to propagate generic argument failures up is not always
reliable, `matchDeepEqualityTypes` should avoid using `TMF_ApplyingFix`
while dealing with optionals and instead let `repairFailures` decide
whether to use generic arguments mismatch fix to a more general one.
If generic arguments mismatch ends up being recorded on the result
of the chain or `try` expression it means that there is a contextual
conversion mismatch.
For optional conversions the solver currently generates a disjunction
with two choices - bind and optional-to-optional conversion which is
anchored on the contextual expression. If we can get a fix recorded
there that would result in a better diagnostic. It's only possible
for optional-to-optional choice because it doesn't bind the
variable immediately, so we need to downgrade direct fixes to prevent
`bind` choice from considered better.
The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
Without contextual information it won't be possible to bind a missing
member to a concrete type later, so let's bind them eagerly and propagate
placeholders outward.
Resolves: rdar://152021264
Resolves: https://github.com/swiftlang/swift/issues/81770
If key or value of a literal collection expression doesn't conform
to protocol(s) expected by the contextual existential type, let's
diagnose that via a tailed collection mismatch fix instead of a
generic conformance one.
Resolves: rdar://103045274
`@autoclosure` is associated with a parameter, we use argument mismatch fix
to diagnose missing explicit calls as well as any mismatches in that position.
Resolves: rdar://110527062
If the argument has an extra `?` or `!`, let's not attempt to force
optional (because it's use is already invalid) and re-introduce
the constraint with unwrapped type instead. This would help to diagnose
the invalid chaining as well as any argument to parameter mismatches.
Resolves: rdar://126080504
When a generic function has potentially Escapable outputs, those outputs
declare lifetime dependencies, which have no effect when substitution
leads to those types becoming `Escapable` in a concrete context.
This means that type substitution should canonically eliminate lifetime
dependencies targeting Escapable parameters or returns, and that
type checking should allow a function value with potentially-Escapable
lifetime dependencies to bind to a function type without those dependencies
when the target of the dependencies is Escapable.
Fixes rdar://147533059.
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
