Even if the requirement is stated on an isolated protocol if the
conformance is implied by a nonisolated one all of the requirements
and witnesses should be nonisolated.
If a `nonisolated` type conforms to a global-isolated protocol
the witnesses to the protocol requirements should infer the
isolation from the protocol but instead be `nonisolated`.
Resolves: rdar://145519840
The execution of these functions is controlled by the testing
framework and it's okay if their behavior changes when the feature
flag is enabled.
Resolves: rdar://152687527
I previously added this hack to match the logic in
`TypeChecker::lookupUnqualified`, but it turns out that can introduce
request cycles for cases where `CodingKeys` is used in a generic
requirement for one of `Codable`'s potential value witnesses. Scale
back the hack such that it's only done when we get an initial empty
lookup result, ensuring we maintain source compatibility. Both these
lookup hacks should go away once we properly handle CodingKeys
synthesis.
rdar://153096639
Escaping solver-allocated types into a nested allocation arena is
problematic since we can e.g lazily compute the `ContextSubMap` for a
`NominalOrBoundGenericNominalType`, which is then destroyed when we
exit the nested arena. Ensure we don't pass any types with type
variables or placeholders to `typesSatisfyConstraint`.
rdar://152763265
Macro expansion can call typeCheckExpr(), which performs qualified
lookups. So if we expand macros while binding extensions, these
qualified lookups can fail because they cannot find members of
extensions that have not been bound yet.
To fix this, try binding extensions without performing macro
expansion first. If any extensions remain at the end, we fall back
to the old behavior, and try to bind them again, this time
performing macro expansion.
Fixes rdar://149798059.
Prevent migration from handling declarations that come from a
module different from the current one, this is primarily a
problem for swiftinterfaces that can get rebuilt when the module
is imported by a model that has migration mode enabled.
Resolves: rdar://152687353
The compiler would previously accept use of `@_inheritActorContext`
on a parameter with a synchronous function type which wasn't marked
as `@isolated(any)`. That is incorrect because in such cases the
attribute has no effect and furthermore would prevent Sendable
and isolation checking.
Uses like that are currently diagnosed by the type-checker but we
need to go one step further and remove the effect in such case to
prevent invalid uses.
Resolves: rdar://143581268
Currently the note is going to point to the "callee" but that is
incorrect when the failure is related to an argument of a call.
Detect this situation in `RValueTreatedAsLValueFailure::diagnoseAsNote`
and produce a correct note.
Resolves: rdar://150689994
No warnings with minimal checking, warnings with `strict-concurrency=complete` and
if declaration is `@preconcurrency` until next major swift version.
Resolves: rdar://151911135
Resolves: https://github.com/swiftlang/swift/issues/81739
If a type gets `Sendable` conformace requirement through another
`@preconcurrency` protocol the error should be downgraded even
with strict concurrency checking to allow clients time to address
the new requirement.
Resolves: rdar://146027395
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.
NFC *except* that I noticed a bug by inspection where we suppress
`@escaping` when print enum element types. Since this affects
recursive positions, we end up suppressing `@escaping` in places
we shouldn't. This is unlikely to affect much real code, but should
still obviously be fixed.
The new design is a little sketchy in that we're using `const` to
prevent direct use (and allow initialization of `const &` parameters)
but still relying on modification of the actual object. Essentially,
we are treating the `const`-ness of the reference as a promise to leave
the original value in the object after computation rather than a
guarantee of not modifying the object. This is okay --- a temporary
bound to a `const` reference is still a non-`const` object formally
and can be modified without invoking UB --- but makes me a little
uncomfortable.
