Skip to content

Conversation

@xedin
Copy link
Contributor

@xedin xedin commented Jun 3, 2025

Cherry-pick of #81779, #81936


  • Explanation:

    This fixes deal with situations that previously caused a fallback diagnostic to be produced.

    • Detect when generic argument mismatch applies to argument and produce a tailed fix
    • Assign missing member eagerly when there is no context
    • Diagnose existential mismatch in a literal collection element position
    • Use argument mismatch fix for @autoclosure result positions
    • Don't attempt to force unwrap invalid optional chaining in the argument position
    • Fix matchDeepEqualityTypes to allow fixing of optionals
  • Main Branch PR: [Diagnostics] A collection of diagnostic fixes/improvements #81779, [CSSimplify] Fix matchDeepEqualityTypes to allow fixing of optionals #81936

  • Risk: Low (Diagnostic improvements only, code doesn't run during normal type-checking).

Resolves: rdar://82971941, rdar://152021264, #81770, rdar://103045274, rdar://110527062, rdar://126080504, #81023, rdar://149843877

  • Reviewed By: @hamishknight

  • Testing: Updated existing tests in the suite, added new test-cases.

xedin added 12 commits June 3, 2025 09:33
… in the argument position

If the argument has an extra `?` or `!`, let's not attempt to force
optional (because it's use is already invalid) and re-introduce
the constraint with unwrapped type instead. This would help to diagnose
the invalid chaining as well as any argument to parameter mismatches.

Resolves: rdar://126080504
(cherry picked from commit ef2fa4a)
…itions

`@autoclosure` is associated with a parameter, we use argument mismatch fix
to diagnose missing explicit calls as well as any mismatches in that position.

Resolves: rdar://110527062
(cherry picked from commit b3e9cf3)
…lement position

If key or value of a literal collection expression doesn't conform
to protocol(s) expected by the contextual existential type, let's
diagnose that via a tailed collection mismatch fix instead of a
generic conformance one.

Resolves: rdar://103045274
(cherry picked from commit d83ec7b)
Without contextual information it won't be possible to bind a missing
member to a concrete type later, so let's bind them eagerly and propagate
placeholders outward.

Resolves: rdar://152021264
Resolves: swiftlang#81770
(cherry picked from commit 10186d6)
…t and produce a tailed fix

The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.

Resolves: rdar://82971941
(cherry picked from commit ded6158)
This is cleanup that allows us to avoid a fallthrough to `ApplyArgToParam`
handling for `inout` failures.

(cherry picked from commit 2d1f9d3)
Since we have `repairViaOptionalUnwrap`, let's use that to fix
argument/parameter mismatches instead of doing ad-hoc matching.

(cherry picked from commit b12d844)
…ch is contextual

If generic arguments mismatch ends up being recorded on the result
of the chain or `try` expression it means that there is a contextual
conversion mismatch.

For optional conversions the solver currently generates a disjunction
with two choices - bind and optional-to-optional conversion which is
anchored on the contextual expression. If we can get a fix recorded
there that would result in a better diagnostic. It's only possible
for optional-to-optional choice because it doesn't bind the
variable immediately, so we need to downgrade direct fixes to prevent
`bind` choice from considered better.

(cherry picked from commit 65e83a8)
Attempting to propagate generic argument failures up is not always
reliable, `matchDeepEqualityTypes` should avoid using `TMF_ApplyingFix`
while dealing with optionals and instead let `repairFailures` decide
whether to use generic arguments mismatch fix to a more general one.

(cherry picked from commit 27c28d4)
…ches

- Mismatch in tuple element position should reference whole tuple
  with a note for mismatch position;
- Situations where optional object type is not a class but matched
  against `AnyObject` have a tailored fix.

(cherry picked from commit 7305275)
…ric argument mismatch handling

(cherry picked from commit 4132aa0)
@xedin xedin requested a review from a team as a code owner June 3, 2025 16:37
@xedin xedin added 🍒 release cherry pick Flag: Release branch cherry picks swift 6.2 labels Jun 3, 2025
@xedin
Copy link
Contributor Author

xedin commented Jun 3, 2025

@swift-ci please test

@xedin xedin merged commit 6e9d97e into swiftlang:release/6.2 Jun 4, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🍒 release cherry pick Flag: Release branch cherry picks swift 6.2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants