In #65125 (and beyond) `matchTypes`, has logic to attempt to wrap an
incoming parameter in a tuple under certain conditions that might help
with type expansion.
In the case the incoming type was backed by a `var`, it would be wrapped
by an `LValueType` then be subsequently mis-diagnosed as not-a-tuple.
More details in #85924 , this this is also the cause of (and fix for)
#85837 as well...
If arguments are represented by a single tuple it's possible
that the issue is not about missing parameters but instead
about tuple destructuring. Fix `fixMissingArguments` to check for
overruns after destructuring and stop if that produces more
arguments then parameters because such situations are better
diagnosed as a general conversion failure rather than a missing
argument(s) problem.
Resolves: rdar://159408715
Make sure we don't produce unnecessary diagnostics while still allowing
things like cursor info to work. No test change since it's covered by
the next commit.
We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
We currently disallow these by deleting them in the `swift` namespace.
This approach has several loopholes, all of which ultimately work
because we happen to define specializations of `simplify_type` for
`swift::Type`:
* `llvm::isa/cast/dyn_cast`. The deleted partial specializations will
not be selected because they are not defined in the `llvm` namespace.
* The argument is a non-const `Type`. The deleted function templates
will not be selected because they all accept a `const Type &`, and
there is a better `Y &Val` partial specialization in LLVM.
* Other casting function templates such as `isa_and_nonull` and
`cast_if_present` are not deleted.
Eliminate these loopholes by instead triggering a static assertion
failure with a helpful message upon instantiation of `CastInfo` for
`swift::Type`.
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.
