If `__attribute__((swift_attr(“@Sendable”)))` is applied to an ObjC method, ObjC property, C field, C variable, or C function, we will now make its result type `Sendable`.
For some entities, this technically had a different behavior previously, because `@Sendable` can be applied to `func`s to indicate that their interface type should be `@Sendable`. We don’t really want people to use this functionality on non-local functions, so we can safely remove it.
This isn’t quite interacting with `Unmanaged` the way we’d want, but I’ve included test cases for the current behavior with FIXME comments.
Fixes rdar://90491024.
When `__attribute__((swift_attr(“@Sendable”)))` is applied to a clang parameter Swift now attempts to make the type `Sendable` in a more comprehensive way than before:
* If it is a function type, it adds `@Sendable` to it.
* If it is a protocol composition type, it adds `& Sendable` to it.
* If it is a class, protocol, or generic class, it inserts it into a protocol composition and adds `& Sendable`.
* If it is a typealias, it *may* desugar it to a modified version of the underlying type.
* In various other cases, it recurses into the children of the type.
This allows Objective-C methods and functions to require that their arguments have a Sendable type without specifying a particular type they must belong to.
Fixes rdar://87727549.
During actor isolation inference, we would unconditionally choose the
isolation of the overridden decl (when, say, there is no attribute on the decl).
The overridden decl is identified with `getOverriddenDecl`.
This works mostly fine, but initializers have some unusual overridden decls
returned by that method. For example, in the following code:
```swift
@objc class PictureFrame: NSObject {
init(size: Int) { }
}
@MainActor
class FooFrame: PictureFrame {
init() {
super.init(size: 0)
}
}
```
that method claims that `FooFrame.init()` overrides `PictureFrame.init()`, when
it really does not! So, if we were to unconditionally take the isolation from
`PictureFrame.init()` (and thus `NSObject.init()`), then we'd infer that
`FooFrame.init()` has unspecified isolation, despite the nominal it resides in
being marked as `MainActor`. This is in essence the problem in SR-15694, where
placing the isolation directly on the initializer fixes this issue.
If `FooFrame.init()` really does override, then why can it be `MainActor`? Well,
we have a rule in one part of the type-checker saying that if an ObjC-imported
decl has unspecified isolation, then overriding it with isolation is permitted.
But the other part of the type-checker dealing with the isolation inference was
not permitting that.
So, this patch unifies how actor-isolation inference is conducted to reuse that
same logic. In addition, the inference now effectively says that, if the decl
has no inferred isolation, or the inferred isolation is invalid according to the
overriding rules, then we use the isolation of the overridden decl. This
preserves the old behavior of the inference, while also fixing this issue with
ObjC declarations by expanding where isolation is allowed.
For example, as a consequence of this change, in the following code:
```swift
@MainActor
class FooFrame: NotIsolatedPictureFrame {
override func rotate() {
mainActorFn()
}
}
```
if `NotIsolatedPictureFrame` is a plain-old not-isolated class imported from
Objective-C, then `rotate` will now have `MainActor` isolation, instead of
having unspecified isolation like it was inferred to have previously. This
helps make things consistent, because `rotate` is allowed to be `@MainActor` if
it were explicitly marked as such.
resolves rdar://87217618 / SR-15694
[CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters
This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
Swift string literals are only permitted to contain well-formed UTF-8, but C does not share this restriction, and ClangImporter wasn't checking for that before it created `StringLiteralExpr`s for imported macros; this could cause crashes when importing a header. This commit makes us drop these macros instead.
Although invalid UTF-8 always *did* cause a segfault in my testing, I'm not convinced that there isn't a way to cause a miscompile with a bug like this. If we somehow did generate code that fed ill-formed UTF-8 to the builtin literal init for Swift.String, the resulting string could cause undefined behavior at runtime. So I have additionally added a defensive assertion to StringLiteralInst that any UTF-8 string represented in SIL is well-formed. Hopefully that will catch any non-crashing compiler bugs like this one.
Fixes rdar://67840900.
If a method has an `async` variant, the non-`async` variant will now mark its completion handler parameter `@Sendable`. This shouldn't be a breaking change in Swift 5 code since these declarations are automatically `@_predatesConcurrency`.
Also adds:
• Support for `@_nonSendable` on parameters, which can be used to override this implicit `@Sendable`
• Support for `@Sendable` on block typedefs; it's generally going to be a good idea to mark completion block typedefs `@Sendable`.
Fixes rdar://85569247.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
Back when we were eagerly importing struct fields, we only attempted to import fields under the names they have in the current version; previous versions and the raw name were ignored. Now that we're importing them lazily, we're passing through code that attempts to import all versions. That's a nice idea in theory, but neither ImportDecl nor the rest of the compiler was prepared for this, and so ImportDecl has started adding redundant stored properties to clang structs. This trips an assertion in IRGen.
This commit returns to the old behavior of only importing struct fields under their current name by simply early-exiting from SwiftDeclConverter::VisitFieldDecl(). We can come up with a solution that imports the variants in the future.
Fixes rdar://86069786.
Adding the ability to add an optional message to the unavailable from
async attribute. This can be used to indicate other possible API to use,
or help explain why it's unavailable.
This patch adds a bunch of tests to verify the behaviour of the
@_unavailableFromAsync attribute.
The attribute is only allowed on functions, so we verify that an error
is emitted when it is applied to structs, extensions, classes, and
actors. The attribute may be applied to constructors to disallow
construction in an async context, but cannot be applied to destructors
since a destructor must be callable from anywhere. Additionally, the
attribute cannot be applied to asynchronous functions since an async
function _must_ be called from an async context.
Specific checks include
- Errors are emitted in an async context (global function, e.g.)
- Errors are emitted when the async context is nested in a sync context
- Errors are not emitted from a sync context nested in an async context
This patch also includes verification that the attribute is propagated
across module boundaries and is be imported from ObjC functions.
Lastly, this patch adds the IDE completion testing to verify that the
attribute is considered.
The `@MainActor(unsafe)` attribute could be provided for C declarations
via the Clang `swift_attr` attribute. However, this facility was never
used outside of tests, and has been superceded by `@MainActor` with the
inferred `@_predatesConcurrency`.
An explicit swift_attr("@_nonSendable") will override it (except for ns_error_domain where the type is embedded in another type that's forced to be Sendable), but swift_attr("@_nonSendable(_assumed)") will not.
...by using `__attribute__((swift_attr("@Sendable")))`. `@_nonSendable` will "beat" `@Sendable`, while `@_nonSendable(_assumed)` will not.
This commit also checks if `SwiftAttr` supports `#pragma clang attribute` and, if it does, defines `__SWIFT_ATTR_SUPPORTS_SENDABLE_DECLS` in imported headers so they know they can apply these attributes in an auditing style.
An explicit swift_attr("@_nonSendable") will override it (except for ns_error_domain where the type is embedded in another type that's forced to be Sendable), but swift_attr("@_nonSendable(_assumed)") will not.
...by using `__attribute__((swift_attr("@Sendable")))`. `@_nonSendable` will "beat" `@Sendable`, while `@_nonSendable(_assumed)` will not.
This commit also checks if `SwiftAttr` supports `#pragma clang attribute` and, if it does, defines `__SWIFT_ATTR_SUPPORTS_SENDABLE_DECLS` in imported headers so they know they can apply these attributes in an auditing style.
Previously, the function emitCBridgedToNativeValue handled three
situations around optionals:
- Bridged?, Native?
- Bridged, Native?
- Bridged, Native
Here, handling for the fourth case
- Bridged?, Native
is added.
To enable this, the number of Optional wrappings that the bridged type
has that the native type does not is passed in to the function. Then,
in the portions of the function where actual transformations are done,
the values are unwrapped an appropriate number of times. Mostly that
means force unwrapping N times before doing the transformation. In the
case of types that conform to _ObjectiveCBridgeable, however, it means
force unwrapping the value N-1 times after doing the transformation
because _ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC
performs one layer of unwrapping itself.
rdar://81590807
We allow import of non-prototyped blocks such as `void (^)()` and treat
them the same way as `void (^)(void)`, so do the same with `async` imports.
Fixes rdar://81239857.
Previously, AbstractionPattern::getOpaque() was used for async
continuations. That was problematic for functions like
```objc
- (void)performVoid2VoidWithCompletion:(void (^ _Nonnull)(void (^ _Nonnull)(void)))completion;
```
whose completion takes a closure. Doing so resulted in attempting to
build a block to func thunk where one of the functions had an out
parameter.
Instead, use the AbstractionPattern(ty).
rdar://79383990
In addition to importing Swift attributes spelled with the C
`__attribute__((swift_attr("...")))`, also import declaration modifiers,
including `nonisolated`.
Fixes rdar://79402200.
The de-duplication checks to preventing redundant mirroring of protocol
declarations failed to consider that a given method could be
implemented as both 'async' and non-'async' declarations, and
therefore would fail to mirror the 'async' form. Account for this
distinction.
Fixes rdar://76799297.
either as an `async` or `async throws` property, by marking it
with swift_async_name("getter:PROPERTY_NAME()") where `PROPERTY_NAME`
will be the name of the property it will be imported as.
This is in lieu of being imported as an async method. It's still
imported as an `@objc` method as well.
This can lead to latent type errors for API users,
because a swiftmodule would otherwise be emitted,
without any diagnostics, containing imported decl
with two global actor annotations on it. Such
decls will always be an error to the typechecker
when its eventually encountered.
This patch drops all `@MainActor` annotations after
the first one in the ClangImporter, regardless of
whether its the safe or unsafe version, and emits
a warning when doing so.
Implicitly add the @completionHandlerAsync attribute for ObjCMethodDecl
that have a completion handler. Adds a link from the non-async to the
async function for use in diagnostics and refactorings.
Resolves rdar://74665226
Import APIs with the `swift_async_error` attribute in `zero_argument` or `nonzero_argument`
modes by checking the corresponding boolean argument to indicate the error status, instead of
treating it as part of the result tuple. rdar://70594666
Plumb generic signatures through the codegen for invoking foreign APIs as async, so that we
correctly handle APIs declared on ObjC lightweight generic classes. rdar://74361267
The Clang importer had some logic to suppress the import of a property that
had the same name as a method with no parameters. This logic
inadvertently meant that an async import of a completion-handler method
could prevent a (non-async) property of the same name to not be
imported, breaking existing code. In such cases, don't suppress the
property import.
Fixes rdar://73326019.
This really only happens when the ClangImporter imports an ObjC
protocol that has an async-looking method, which yields two
requirements in the protocol. Only one of these requirements
will be witnessed.
fixes rdar://73326224
The bridging code handles optional wrapping and unwrapping, but in cases where a nullable completion
callback argument did not need bridging, it would get short circuited out of the bridging code, and
did not get unwrapped. Fixes rdar://73798726
