When targeting a platform that predates the introduction of isolated
deinit, make a narrow exception that allows main-actor-isolated deinit
to work through a special, inlineable entrypoint that is
back-deployed. This implementation
1. Calls into the real implementation when available, otherwise
2. Checks if we're on the main thread, destroying immediately when
we are, otherwise
3. Creates a new task on the main actor to handle destruction.
This implementation is less efficient than the implementation in the
runtime, but allows us to back-deploy this functionality as far back
as concurrency goes.
Fixes rdar://151029118.
If `LinkEntity::isTypeKind()` is true, `IRGenModule::getAddrOfLLVMVariable`
assumes that we can safely call `LinkEntity::getType()`, which does
`reinterpret_cast` of `LinkEntity::Pointer` to `TypeBase *`. However, for SIL
differentiability witness, the pointer has `SILDifferentiabilityWitness *`
type, which is not derived from `TypeBase`. So, such a cast is not allowed.
Just as with `ProtocolWitnessTableLazyAccessFunction` and
`ProtocolWitnessTableLazyCacheVariable` link entity kinds (which are
also type kinds), we should use `SecondaryPointer` instead of `Pointer` for
storing payload here, while setting `Pointer` to `nullptr`.
(cherry picked from commit 77a3873448)
Adjust isolation checking to handle misused `isolated` attribute
and let attribute checker property diagnose it.
Resolves: rdar://148076903
Resolves: https://github.com/swiftlang/swift/issues/80363
(cherry picked from commit 358067917e)
Integer literal expressions with types that are not of type `int` are
printed with a suffix to indicate the type (e.g. `123U` or `456L` for
`unsigned` and `long`). This is not valid syntax for integer literals in
Swift, so until we fully translate the count expr syntax to Swift we
need to avoid importing these count expressions.
Also fixes some -Werror related stuff in test cases.
rdar://154141719
(cherry picked from commit 374658a)
When improving the speed of dependency scanning when the new clang API
to speed up bridging, some unintended change was introduced. This
restore the scanner to the behavior before #81454
rdar://153851818
(cherry picked from commit cebe173ada)
Diagnostics can outlive the ConstraintSystem itself if we have a
diagnostic transaction for e.g `typeCheckParameterDefault`, make sure
we don't try to use a solver-allocated type as an argument.
use local funcs to implement `defer`, this also fixes several
bugs with that feature, such as it breaking in nonisolated
functions when a default isolation is in effect in the source file.
Change how we compute isolation of local funcs. The rule here is
supposed to be that non-`@Sendable` local funcs are isolated the
same as their enclosing context. Unlike closure expressions, this
is unconditional: in instance-isolated functions, the isolation
does not depend on whether `self` is captured. But the computation
was wrong: it didn't translate global actor isolation between
contexts, it didn't turn parameter isolation into capture isolation,
and it fell through for several other kinds of parent isolation,
causing the compiler to try to apply default isolation instead.
I've extracted the logic from the closure expression path into a
common function and used it for both paths.
The capture computation logic was forcing a capture of the
enclosing isolation in local funcs, but only for async functions.
Presumably this was conditional because async functions need the
isolation for actor hops, but sync functions don't really need it.
However, this was causing crashes with `-enable-actor-data-race-checks`.
(I didn't investigate whether it also failed with the similar
assertion we do with preconcurrency.) For now, I've switched this
to capture the isolated instance unconditionally. If we need to
be more conservative by either only capturing when data-race checks
are enabled or disabling the checks when the isolation isn't captured,
we can look into that.
Fix a bug in capture isolation checking. We were ignoring captures
of nonisolated declarations in order to implement the rule that
permits `nonisolated(unsafe)` variables to be captured in
non-sendable closures. This check needs to only apply to variables!
The isolation of a local func has nothing to do with its sendability
as a capture.
That fix exposed a problem where we were being unnecessarily
restrictive with generic local func declarations because we didn't
consider them to have sendable type. This was true even if the
genericity was purely from being declared in a generic context,
but it doesn't matter, they ought to be sendable regardless.
Finally, fix a handful of bugs where global actor types were not
remapped properly in SILGen.
This reverts a revert that was done internally here https://stashweb.sd.apple.com/projects/DEVTOOLS/repos/swift/pull-requests/8697/overview
and corrects some issues with the reverted code while at it.
This fix is crucial to land for correctness and necessary to fix the
rdar://144568615 which had a fix submitted however that assumed that
THIS change also was present, so the fix submitted for 144568615 is
incomplete without this change as well.
This enables, and adds more TBD testing and was explicitly checked
against the GameKit reproducer project from rdar://144568615.
I will also upstream the necessary parts missing from OSS repo there so
we have alignment between all branches.
ObjC ivar metadata has up to now emitted an empty string for the ivar's objc type encoding. Conversely, ObjC property metadata is emitted with an objc type encoding. This changes the compiler to also emit an objc type encoding for ivars.
The motivation for this change is for lldb to print ivars of classes declared in Objective-C but implemented in Swift, as defined in [SE-0436](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0436-objc-implementation.md). Without the presence of type encoding for ivars, lldb is unable to present to the user the ivars/properties of instances of such classes.
rdar://138569299
(cherry picked from commit ce7a3b39a4)
When the default isolation is main-actor, don't infer @MainActor
for a type that conforms to a protocol P in its primary definition when
P inherits from Sendable. Such types should remain non-isolated
because they're highly unlikely to be able to implement the P
conformance (which cannot be isolated).
Put this feature behind a new experimental flag,
SendableProhibitsMainActorInference.
Implements rdar://151029300
Returning the unsubstituted superclass type is not correct,
because it may contain type parameters. Let's form a new
UnboundGenericType instead.
- Fixes https://github.com/swiftlang/swift/issues/82160.
- Fixes rdar://152989888.
Adjust the downgrade check for static member references to
account for the fact that argument could come of a tuple or
some other reference that doesn't have a declaration associated
with it.
Resolves: rdar://153083848
(cherry picked from commit 3ae8d5680f)
Narrowly fix a long-standing bug where destroy_addrs would be hoisted
into read access scopes, leaving the scope as a read despite the fact
that it modifies memory. This is a problem for utilities which expect
access scopes to provide correct summaries. Do this by refusing to fold
into access scopes which are marked `[read]`.
In a follow-up, we can reenable this folding, promoting each access
scope to a modify. Doing so requires checking that there are no access
scopes which overlap with any of the access scopes which would be
promoted to modify.
rdar://154407327
Bail if the closure captures an ObjectiveC block which might _not_ be copied onto the heap, i.e optimized by SimplifyCopyBlock.
We can't do this because the optimization inserts retains+releases for captured arguments.
That's not possible for stack-allocated blocks.
Fixes a mis-compile
rdar://154241245
Unfortunately haven't been able to come up with a test case for this,
but there seem to be cases where we're incorrectly picking up
a macro-expanded accessor from the cached AST when searching for the
original decl. Make sure we only consider decls that have been
written by the user.
rdar://151926231
AllowDeserializingImplementationOnly was historically added as a defensive
check against deserailzation issues introduced by @implementationOnly imports.
It's no longer specified by other tools, thus the ABI checker should drop
it as well.
rdar://153683760
Users commonly try to write a lifetime dependency on an 'inout' parameters as:
@_lifetime(a: &a)
func f_inout_useless(a: inout MutableRawSpan) {}
This is useless. Guide them toward what they really wanted:
@_lifetime(a: copy a)
Fixes rdar://151618856 (@lifetime(..) gives inconsistent error messages)
(cherry picked from commit 87f2510a27)
This is a common mistake made more common be suggestions of existing diagnostic
that tell users not to use a 'copy' dependency.
Report a diagnostic error rather than crashing the compiler. Fix the diagnostic
output to make sense relative to the source location.
Fixes rdar://154136015 ([nonescapable] compiler assertion with @_lifetime(x: inout x))
(cherry picked from commit 080b68292d)
Correctly diagnose this as:
"invalid use of inout dependence on the same inout parameter
@_lifetime(a: &a)
func f_inout_useless(a: inout MutableRawSpan) {}
Correctly diagnose this as:
"lifetime-dependent parameter must be 'inout'":
@_lifetime(a: borrow a)
func f_inout_useless(a: borrowing MutableRawSpan) {}
(cherry picked from commit 05fa82b7a7)
This comes up often when passing a MutableSpan as an 'inout' argument. The
vague diagnostic was causing developers to attempt incorrect @_lifetime
annotations. Be clear about why the annotation is needed and which annotation
should be used.
(cherry picked from commit df0b81c88d)
