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.
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.
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).
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.
- Introduce a generic requirements opening function for type resolution,
which is used by the constraint system in cases where we need to
impose requirements on opened type variables.
- Refactor `replaceInferableTypesWithTypeVars` to use this function
when opening generic types that contain either placeholder or unbound
generic types.
Together these changes ensure that we don't drop generic requirements
when an unbound generic or placeholder type is used as a generic
argument.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
Previously this would result in a fallback diagnostic because
type mismatches associated with `ExistentialConstraintType`
locations weren't handled at all.
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
Generic arguments types are not always resolved enough to enable
aggregated mismatch fixes, which means that the solver should be
able to handle standalone generic argument matching constraints
and create a fix per mismatch location to coalesce them during
diagnostics.
Resolves: rdar://106054263
Aggregate all requirement failures (regardless of kind) that belong
to the same locator and diagnose them as an ambiguity (if there is
more than one overload) or as the singular failure if all solutions
point to the same overload.
If a constraint has fully resolved but incorrect (not simplifiable)
dependent member types, let's diagnose that as a contextual mismatch
instead of failing (which sometimes leads to a fallback diagnostic).
Resolves: rdar://101412179
If all solutions point to the same overload choice that needs
re-labeling it's safe to diagnose it as if there was no ambiguity
because the call site is static.
If one of the sides in a application result conversion is a hole
it could only mean that the fix has been recorded earlier (at the
point where hole was introduced) and failure at function result
position could be safely ignored.
Resolves: rdar://79757320
Without context synthesized argument would be inferred as a hole,
so let's not record any additional fixes for it if there is no way
to infer it properly from a parameter (which could also be a hole
if it is a generic parameter type).
Resolves: rdar://78781552
If relational constraint has the same dependent member type on both
sides e.g. `$T1.Element == $T1.Element` allow its simplification,
since inference of `$T1` results in dependent member being resolved
to the same concrete type. Otherwise constraint system would be left
with this constraint in inactive state if `$T1` couldn't be resolved
which results in a crash.
Resolves: rdar://78623338
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
automatically.
This commit also renames `ConstraintSystem::recordHole/isHole` to
`recordPotentialHole` and `isPotentialHole` to make it clear that
we don't know for sure whether a type variable is a hole until it's
bound to unresolved.
Argument-to-Parameter mismatch handles conformance failures
related to arguments, so the logic in `MissingConformanceFailure`
which wasn't entirely correct is now completely obsolete.
Resolves: rdar://problem/56234611
Conformance requirements get their fixes attached directly where
other requirements have to use (for now) `repairFailure` mechanism.
Regardless of _how_ fixes get recorded there should be a single
way to assess impact of a particular requirement failure.
The rules are:
- If this is a requirement associated with an operator, impact
is based on use of the type which failed the requirement;
- If this requirement is from conditional extension,
it is considered a very high impact because failing such
requirement makes referenced member de facto invisible.
Resolves: rdar://problem/55593998
Resolves: [SR-11491](https://bugs.swift.org/browse/SR-11491)
Have FailureDiagnostic::getChoiceFor take a ConstraintLocator argument
which is passed through to getAnchormostCalleeLocator, and rename to
getAnchormostChoiceFor to make the semantics clear. In addition, add
a convenience getAnchormostChoice member for the common case of getting
the choice for the anchor of the failure's locator.
This change means we can now resolve callees for failures associated
with key path subscript components.
Resolves SR-11435.
Previously in situations like:
```swift
protocol P {}
struct S<T: P> {
var value: T
}
_ = S(value: 42)
```
Diagnostic has reported a problem as related to "reference" to `init`
but the failing generic type requirement belongs to `S`, so a
better diagnostic in such case should mention `generic struct S`.
