Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
The pack expansion type variable may be a nested in the fixed type of
another type variable, and as such we unfortunately need to fully
`simplifyType` here.
rdar://162545380
For a Bind constraint generated by a same-type requirement, we must
preserve the locator so we need to record it like any other kind of
constraint.
This fixes a diagnostic regression with -solver-enable-prepared-overloads.
Dependent members cannot be simplified if base type contains unresolved
pack expansion type variables because they don't give enough information
to substitution logic to form a correct type. For example:
```
protocol P { associatedtype V }
struct S<each T> : P { typealias V = (repeat (each T)?) }
```
If pack expansion is represented as `$T1` and its pattern is `$T2`, a
reference to `V` would get a type `S<Pack{$T}>.V` and simplified version
would be `Optional<Pack{$T1}>` instead of `Pack{repeat Optional<$T2>}`
because `$T1` is treated as a substitution for `each T` until bound.
Resolves: rdar://161207705
Matching existential types could introduce `InstanceType` element
at the end of the locator path, it's okay to look through them to
diagnose the underlying issue.
This is a narrow workaround for a regression from
9e3d0e0a8c.
There is no reason to skip this logic for protocol extension
members, except that doing so happens to break existential
opening in an expression that involves a call to Array.init
elsewhere.
However there is an underlying issue here with existential opening,
which doesn't seem to work right in the presence of overloading.
The test case demonstrates the fixed problem, together with an
existing bug that points to the underlying problem.
Fixes rdar://160389221.
We allow placeholder types in interface types in certain cases to allow
better recovery since we can suggest the inferred type as a replacement.
When referencing those decls though we need to make sure we record a fix
since we cannot form a valid solution with them.
`KeyPath` types now have conformance requirements placed on their
`Root` and `Value` types which need to be checked even when there
is a key path to function conversion involved, otherwise the solver
would be accepting invalid code.
Note that without function conversion the requirements come from
a type opened during assignment - https://github.com/swiftlang/swift/pull/80081/files.
Resolves: https://github.com/swiftlang/swift/issues/84150
Eagerly bind invalid type references to holes and propagate contextual
type holes in `repairFailures`. This avoids some unnecessary diagnostics
in cases where we have an invalid contextual type.
If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
If the base type is composed with marker protocol(s) i.e.
`<<Type>> & Sendable`, let's skip this check because such
compositions are always opened and simplified down to a
superclass bound post-Sema.
Resolves: rdar://148782046
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
