The first bug is that we weren't computing isolation correctly for
nested defers. This is an unlikely pattern of code, but it's good to fix.
The second bug is that getActorIsolationOfContext was looking through
defers, but getActorIsolation itself was not. This was causing defer
bodies to be emitted in SILGen without an isolation parameter, which
meant that #isolation could not possibly provide the right value. Fixing
this involves teaching SILGen that non-async functions can have
nonisolated(nonsending) isolation, but that's relatively straightforward.
This commit doesn't fix #isolation or adequately test SILGen, but that'll
be handled in a follow-up.
Explanation: We generate declarations in the C++ interop header with
"unavailable" annotations when we cannot export something to C++. These
declarations can collide with existing names. Previously, there were no
ways to resolve these name collisions. This PR introduces a new
attribute to hide declarations from the interop header.
Issues: rdar://158843666
Original PRs: #82616
Risk: Low, this adds a new, straightforward code path.
Testing: Added a compiler test.
Reviewers: @egorzhdan
This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
(cherry picked from commit fe1ae75711)
Just like `@preconcurrency` for concurrency, this attribute is going
to allow exhaustiveness error downgrades for enums that were retroactively
marked as `@extensible`.
(cherry picked from commit 498430afaf)
Guard against condfails when older compilers get a swift interface
that uses `@extensible` attribute. The attribute itself doesn't
have any effect in swift interfaces yet since all of the public
enums are already resilient in that mode.
(cherry picked from commit 6d89bca765)
For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
(cherry picked from commit bf19481ab6)
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
(cherry picked from commit a0ae93d3a8)
Explanation: The original code had the assumption we only import
modules. However, there is a flag to import an umbrella header in which
case the clang nodes have no owning module. This PR prevents a null
dereference in that case.
Issues: rdar://157489426
Original PRs: #83540
Risk: Low, added a check to avoid null dereference.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Explanation: We the generated reverse interop headers to be valid C++,
so every declaration coming from an Obj-C module should be behind an
ifdef. Unfortunately, we do not always have this information but we do
know that our frameworks contain Obj-C code. So this PR makes sure every
entity coming from our frameworks are behind ifdef.
Issues: rdar://152836730
Original PRs: #83002
Risk: Low, the change is narrow and straightforward.
Testing: Added a compiler test.
Reviewers: @egorzhdan
Explanation: C++ interop synthesizes certain forwarding functions in an
_ObjC module. This confuses MemberImportVisibility. This patch adds
logic to work this around by keeping a mapping between the synthesized
and the original function and looks up where the synthesized functions
belong to based on the original functions' parent module.
Scope: C++ forward interop when MemberImportVisibility is enabled.
Issues: rdar://154887575
Original PRs: #82840
Risk: Low, a narrow change makes getModuleContextForNameLookupForCxxDecl more
precise, and it is only used with MemberImportVisibility.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @tshortli, @hnrklssn
Forming an isolated conformance to a SendableMetatype-inherting
protocol opens up a soundness hole any time the conformance is used.
Reword the recently-introduced diagnostic for this case and promote it
to an error (except when it's preconcurrency).
Fixes rdar://154808002.
`LifetimeDescriptor::getName()` can crash if the descriptor had a `self`.
Replace with `LifetimeDescriptor::getString()`
(cherry picked from commit 6d0a6d2760)
Adds an access control field for each imported module identified. When multiple imports of the same module are found, this keeps track of the most "open" access specifier.
Split out the state mutation into a new `updateFor`
function that we call for diagnostic emission, allowing
`DiagnosticTransaction::hasErrors` to query the behavior without
mutating any state.
If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
If a Swift class has a field, which has a closure type, which takes an instance of a `CF_OPTIONS`/`NS_OPTIONS` type as a parameter, the reverse interop logic would generate an invalid Objective-C++ header for such type.
This was discovered with UIKit's `UIControlState` type, which is declared with `NS_OPTIONS` in Objective-C, then renamed to `UIControl.State` with API Notes, and then re-exported to Objective-C++ via the generated header.
rdar://129622886
(cherry picked from commit e95c9ecffc)
- **Explanation**: USR mangling can include an extension context infix
(`AAE`) when an extended type uses `@_originallyDefinedIn` on platforms
other than the active one. This adds a check for the
`RespectOriginallyDefinedIn` flag when checking extension decls against
their extended type.
- **Scope**: Changes USR mangling in these situations so that USRs are
the same for the same code regardless of platform.
- **Issues**: rdar://152598492
- **Original PRs**: https://github.com/swiftlang/swift/pull/82348
- **Risk**: Low. The change is limited to situations where the name
mangler is already disrespecting the alternate module name, and only
additionally turns on that flag for any USR mangling.
- **Testing**: Automated tests
- **Reviewers**: @edymtt @augusto2112
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.
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.
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)
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)
We sometimes mangle SILFunctionTypes when generating debug info
for reabstraction thunks, and these can have various exotic
parameter and result attributes. Two recent additions were
never plumbed through the mangler, causing assertion failures
when emitting debug info.
Fixes rdar://153730847.
