Commit Graph

5 Commits

Author SHA1 Message Date
Hamish Knight
5c3f6703a0 Remove diag::type_of_expression_is_ambiguous
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
2025-08-19 17:14:23 +01:00
Holly Borla
f1cd9cb422 [Test] Remove REQUIRES: asserts from tests that use -swift-version 6. 2024-02-13 07:13:35 -08:00
Slava Pestov
1957bd6065 Sema: Reword diagnostics to say 'without a type annotation' instead of 'without more context' 2023-06-09 17:44:42 -04:00
Hamish Knight
4aaec65780 [CS] Warn on mismatched tuple labels for subtyping
This is something that we'd like to fix to bring
in line with tuple conversion, so start warning on
cases where it occurs.
2021-11-17 17:06:21 +00:00
Hamish Knight
da36a2cb88 [CS] Restore a type variable for compatibility with rdar://85263844
Despite being otherwise disconnected from the
constraint system, it's possible for it to affect
how we type-check tuple matches in certain cases.

This is due to the fact that:
- It can have a lower type variable ID than an
opened generic parameter type, so becomes the
representative when merged with it. And because it
has a different locator, this can influence
binding prioritization.
- Tuple subtyping is broken, as it's currently a
*weaker* relationship than conversion.

Therefore, temporarily restore this bit of logic
for language versions < 6. If possible, we should
try and fix tuple subtying in Swift 6 mode to not
accept label mismatches, so that it's not more
permissive than tuple conversion.

rdar://85263844
2021-11-17 17:06:19 +00:00