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.
`??` operator is overloaded on optionality of its result. When the
first argument matches exactly, the ranking is going to be skewed
towards selecting an overload choice that returns a non-optional type.
This is not always correct i.e. when operator is involved in optional
chaining. To avoid producing an incorrect favoring, let's skip the this
disjunction when constraints associated with result type indicate
that it should be optional.
Simply adding it as a binding won't work because if the second argument
is non-optional the overload that returns `T?` would still have a lower
score.
Resolves: rdar://164201746
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.
This is a fix for the ported "calls with a single unlabeled argument"
hack. If overload doesn't match context on async effect, let's not favor
it because that is more important than defaulted parameters.
Resolves: rdar://164269641
I missed upgrading this to an error for Swift 6 mode, let's upgrade it
to an error for a future language mode. It's important we reject these
cases since we're otherwise allowing subtyping to be a weaker constraint
than conversion.
Update special favoring logic for unlabeled unary calls to support
non-overloads member references in argument positions.
The original hack missed a case where a type of a member is known
in advance (i.e. a property without overloads) because there as
another hack (shrink) for that.
This helps in situations like `Double(x)` where `x` is a property
of some type that is referenced using an implicit `self.` injected
by the compiler.
Resolves: rdar://161419917
This works around the fact that existential opening does not currently
work correctly in cases where the argument isn't resolved before the
applicable fn is solved.
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
This appears to only support synthesized conformances because
operators in such cases use different names - `__derived_*`.
These days devirtualization like this is performed as part of
mandatory inlining. And this approach doesn't stack well with
features like `MemberImportVisibility` because there is change
to check whether witness is available or not.
This helps avoid producing more downstream errors. This changes
`GenericSignature::forInvalid` to produce the same signature as e.g
`<T where T == Undefined>`. This subsumes the need to introduce
conformance requirements for invertible protocols.
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
This adds the -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at <unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated, but by being strict by default it should make it harder to accidentally miss diagnostics.
To avoid unnecessary performance overhead, -verify-additional-file is still required to parse the expected-* directives in files other than the main file.
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.
Make sure we canonicalize the original type for an ErrorType to ensure
that diagnostic logic can coalesce ErrorTypes that have the same
canonical type.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
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.
For non-generic cases we can simply recurse into the underlying type,
ensuring we don't crash with a null GenericSignature. For generic
cases, ensure we bind outer generic parameters to their archetypes,
and apply the substitutions to the original underlying type to ensure
we correctly handle cases where e.g an unbound generic is passed as
a generic argument to a generic typealias.
rdar://160135085
Temporarily disable the checking requirements for typealias types,
and desugar the typealias since the constraint system does not
currently correctly handle type variables in the underlying type.
Since we can run CSGen multiple times, we need to guard the emission
of the note on whether the TypeRepr was already marked invalid (i.e
whether we already emitted a diagnostic for it).
This normally gets populated by successful type-checking, we still want
to populate it if we fail though to avoid attempting to type-check the
parent statement again.
This type is only intended for pattern matching against `nil`
and the solver shouldn't early attempt to infer this type for
`nil` for arguments of `==` and `!=` operators it should instead
be inferred from other argument or result.
Resolves: rdar://158063151
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
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.
