Add a separate method `fixForHole` on `TypeVariableBinding`
responsible for determining whether fix is required and if so,
what kind of fix to apply when a particular type variable is
resolved to a hole.
If subtyping is allowed for a result type of an implicit member chain,
let's delay binding it to an optional until its object type resolved too or
it has been determined that there is no possibility to resolve it.
Otherwise we might end up missing solutions since it's allowed to
implicitly unwrap base type but it can't be done early - type variable
representing chain's result type has a different l-valueness comparing
to generic parameter of an optional.
This used to work before due to a hack in constraint generator where
unresolved member with arguments would return base type (which
doesn't allow l-value) instead of a result type.
Resolves: rdar://problem/68094328
This is NFC because only literal protocols are tracked at the moment.
Forward propagate (subtype -> supertype) only literal conformance
requirements since that helps solver to infer more types at
parameter positions.
```swift
func foo<T: ExpressibleByStringLiteral>(_: String, _: T) -> T {
fatalError()
}
func bar(_: Any?) {}
func test() {
bar(foo("", ""))
}
```
If one of the literal arguments doesn't propagate its
`ExpressibleByStringLiteral` conformance, we'd end up picking
`T` with only one type `Any?` which is incorrect.
This is not going to be necessary once bindings are filtered based
of requirements placed on a type variable.
when we have an optional type. This uncovered an error with unresolved member lookup where we allowed an unresolved value member constraint to fail if lookup failed in an optional type wrapping a type variable.
This resolves SR-13357.
If a type variable doesn't have any "direct" bindings let's not
consider it as viable to be attempted next. Such type variables
are helps purely to accommodate transitive binding inference
for other members of subtype chain.
Resolves: rdar://problem/66234725
Split `getPotentialBindings` in two:
- `inferBindingsFor` should take responsibility for binding constraints
to be evaluated as potential binding sources;
- `PotentialBindings::infer` would process constraints provided by
`inferBindingsFor` and "extract" bindings from them.
This is done to separate "sourcing" logic from "inference" and
make the former pluggable, so bindings could be computed based
on changes in constraint graph in the future.
It's possible to find current type variable while trying to infer
transitive bindings (because sources are gathered from multiple
different type variables and current type variable could be a
representative of an equivalence class), let's make sure we don't
attempt to use constraints which refer to current type variable
on the left-hand side.
Resolves: rdar://problem/65724310
In situations like:
$T0 subtype $T1
$T1 literal conforms to ExpressibleByArrayLiteral
$T0 conv [<Type>]?
We have to ensure that $T0 gets to maintain its optionality
because $T1 then could strip optionality later based on a
typing rule where `T <: T?`
Let's try to coalesce integer and floating point literal protocols
if they appear together because the only possible default type that
could satisfy both requirements is `Double`.
Since bindings now require finalization we need a new endpoint
which perform all of the required actions before returning complete
`PotentialBindings` object when they are requested for a particular
type variable without any other context.
If `Any` has been inferred as a non-default binding (e.g.
if parameter has `Any` type) let's give it the lowest
priority and attempt after any other bindings (including
literal ones) because it's better to infer some concrete
type and then erase it to `Any` if required by the
constraint system.
Based on collected direct and transitive information about protocol
requirements let's determine literal protocol coverage by existing
bindings as well as any default types which have to be introduced
to the set as part of finalization phase.
If type variable is expected to conform to `ExpressibleByNilLiteral`
adjust optionality of the inferred bindings only after all of the
bindings have been collected otherwise transitive supertype bindings
are going to stay non-optional which is incorrect.
To preserve subtype relationship between element types of a collection
passed as an argument to a parameter represented by another collection
type let's extend opening of the collection types to be done for arguments
to @autoclosure parameters as well because implicit closure is transparent
to the caller.
Resolves: [SR-13135](https://bugs.swift.org/browse/SR-13135)
Resolves: rdar://problem/65088975
* [TypeCheckConstraints] Adjusting cases where checked casts that cannot be determined statically were producing misleading warnings
* [tests] Adding regression tests for SR-13088
* [TypeCheckConstraints] Adjusting comment and adding an extra test case for SR13035
* [TypeCheckConstraints] Fixing typos in comments
* [AST] Moving implementation of isCollection from ConstraintSystem to AST TypeBase
* [TypeCheckConstraints] Adjusting logic to verify specific conformance to stdlib collection type before emit an downcast warning
* [TypeCheckConstraints] Creating new CheckedCastContextKind::CollectionElement to be able to verify special cases within typeCheckCheckedCast for collection elements
* [TypeCheckConstraints] Adjusting logic around generic substitution to check both subtype and supertype
* [Sema] Adding isKnownStdlibCollectionType and replacing all usages contraint system method
* [TypeChecker] Reverting fixes around array element types
* [TypeChecker] Abstract logic of check for conditional requirements on TypeChecker::couldDynamicallyConformToProtocol
* [TypeChecker] Ajdustinc can conformDynamically conform and adjust review comments
* [TypeChecker] Ajusting comments and fixing typos
* [TypeChecker] Adjusting existential and archetype logic to check inside couldDynamicConform
* [TypeChecker] Adjusting minor and adding existential check into couldDynamically conform.
* [TypeChecker] Adjusting comments
Instead of special casing argument-to-parameter matching for
object literal expressions, let's allow constraint system to
lookup a witness initializer and apply it to the given set
of arguments.
This also simplifies constraint application because
`coerceCallArguments` could be used to form type-checked
argument expression.
Disallow holes to be inferred as supertype bindings while inferring
bindings from other type variables (based on transitivity of subtype
conversions), otherwise it would be possible to record a hole without
recording associated fix.
Resolves: rdar://problem/64368545
Introduce an experimental mode (behind the flag
`experimental-one-way-closure-params`) that places one-way
constraints between closure parameter types and references to those
parameters within the body of the closure. The intent here is to
break up constraint systems further, potentially improving type
checking performance and making way for larger closure bodies to be
supported.
This is a source-breaking change when the body of a single-expression
closure is used to determine the parameter types. One obvious example
is when there is no contextual type, e.g.,
let _ = { $0 + 1 }
this type-checks today because `1` becomes `Int`, which matches the
`+` overload with the type `(Int, Int) -> Int`, determining the
parameter type `Int` for the closure. Such code would not type-check
with one-way constraints.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
