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.
Non-escapable struct definitions often have inicidental integer fields that are
unrelated to lifetime. Without an explicit initializer, the compiler would infer
these fields to be borrowed by the implicit intializer.
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
/* infer: @lifetime(copy span, borrow i) init(...) */
}
This was done because
- we always want to infer lifetimes of synthesized code if possible
- inferring a borrow dependence is always conservative
But this was the wrong decision because it inevitabely results in lifetime
diagnostic errors elsewhere in the code that can't be tracked down at the use
site:
let span = CountedSpan(span: span, i: 3) // ERROR: span depends on the lifetime of this value
Instead, force the author of the data type to specify whether the type actually
depends on trivial fields or not. Such as:
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
@lifetime(copy span) init(...) { ... }
}
This fix enables stricter diagnostics, so we need it in 6.2.
Fixes rdar://152130977 ([nonescapable] confusing diagnostic message when a
synthesized initializer generates dependence on an Int parameter)
(cherry picked from commit 8789a686fed869e3cd7bc4e748a443e71df464e1)
This avoids diagnostic errors on synthesized accessors, which are impossible for developers to understand.
Fixes rdar://153793344 (Lifetime-dependent value returned by generated accessor '_read')
(cherry picked from commit 855b3e4446)
If two conformances imply a conformance to the same marker
protocol, don't diagnose redundancy if they differ by
unavailability. Instead, allow the more available conformance
to win.
This allows declaring a type that conforms to a protocol
that inherits from SendableMetatype, followed by an
unavailable Sendable conformance on the same type.
Fixes rdar://152509409.
If a C++ namespace has redeclarations in a bridging header, printing AST for the namespace would crash the compiler. This is because such a redeclaration would not have an owning Clang module, and the AST printer did not account for that.
This change fixes the crash.
rdar://151715540
(cherry picked from commit cc9c51deea)
