Missed this in my original patch, handle pack parameters the same as
regular generic parameters, ensuring we don't prefer a pack overload
over a generic overload just because there are pointer conversions
involved. Note this doesn't fix the wider issue of rdar://122011759,
I'm planning on looking into that in a follow-up.
These methods can be simplified a bunch since the returned decl is
always the input decl and we can refactor the lambdas to just return
the auxiliary variable and have the type computation in the caller.
Builtin.FixedArray was introduced as the first generic builtin type, with
special case handling in all the various recursive visitors. Introduce
a base class, and move the handling to that base class, so it is easier
to introduce other generic builtins in the future.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Add the application constraint before the member constraint, which
allows us to get rid of the special-cased delaying logic for dynamic
member subscripts. The diagnostic change here is due to the fact that
we no longer have a simplified type for the result in CSGen, which
would also be the case if we had a disjunction for the member.
We ought to consider outright banning these conversions if the
destination is a generic parameter type, but for now let's penalize
them such that we don't end up with ambiguities if you're doing an
implicit pointer conversion through an identity generic function.
rdar://161205293
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
