This fixes an ambiguity introduced by the stdlib change in
0f99458900.
Since (borrowing T) -> () and (T) -> () both convert to
each other, we could end up with ambiguous solutions where
neither one was better than the other. Generalize the
existing trick we use for labeled vs unlabeled tuples to
also strip off ownership specifiers and @convention(...)
from function types. This fixes the regression, as well
an existing FIXME in a test I added a while ago where
the same problem arises with @convention(block).
A key path component that resolved to an `ErrorExpr` would be diagnosed twice: once when the `ErrorExpr` was created, then again when it was processed. Fix this redundant diagnostic.
The legacy parser has a special case for code like `fn(:)` which corrects it to `fn(_:)`, but the new `::` token was interfering with cases where there were two adjacent colons (e.g. `fn(::)`). Correct this issue.
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.
This never worked correctly and would crash in SILGen, ban the use
of placeholder types. While here, ensure we replace any ErrorTypes
with holes when solving the closure in the constraint system.
This change adds detection for nested type references in KeyPath
components and applies the appropriate fix to generate meaningful error
messages, following the same pattern already established for method
references.
The fix ensures that invalid KeyPath references fail gracefully in
normal mode and provide helpful diagnostics in diagnostic mode,
improving the developer experience when working with KeyPaths.
Resolves: https://github.com/swiftlang/swift/issues/83197
Diagnose the availability of the specific accessors that are referenced
implicitly via a key path reference. This causes setter availability to be
diagnosed when passing a key path to a function that takes a `WritableKeyPath`.
Resolves rdar://157232221.
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.
In implicit contexts that are universally unavailable, allow writable key paths
to be formed to properties with setters that are also marked as universally
unavailable. This fixes a regression from the previous commit where the code
synthesized for `@Observable` properties in universally unavailable classes was
rejected by the availability checker.
Previously, only conditional unavailability was considered, but setters that
are always unavailable must also make a keypath read-only.
Resolves rdar://155832511.
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
This test creates an object then checks a weak reference to that object on a background thread. It was doing this check after 10ms, and any small hiccup could potentially delay the object's destruction enough to spuriously fail.
Rearrange the test to check the weak reference in a loop for several seconds before giving up. This makes it very fast on success (it's done the moment it sees nil) while being robust against up to several seconds of delay in destroying the object if that happens.
rdar://149868181
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
Handle PatternBindingDecls with missing var locations, which can
happen for loop iterator vars, and FuncDecls with missing name and
func locations, which can happen for `defer`. Also while here make
sure we set the source location of a parser-produced ErrorExpr.
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
Additional restrictions on when protocol inference could be considered
viable. If the chain is connected directly to a contextual type there
cannot be any other inference sources for the base type.
Resolves: rdar://148256978
When we encounter unsafe code in `if let x`, we would produce a Fix-It
that would change it to the ill-formed `if let unsafe x`. Improve
tracking of the expressions that are synthesized for the right-hand
side of these conditions, so that we can produce a Fix-It that turns
this into the proper
if let x = unsafe x
Fixes rdar://147944243.
