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.
Unlike normal Objective-C functions, Swift does not directly call
Objective-C constructors because it creates a thunk to allocate the
object and call then constructor dynamically. This can be fixed, but for
now emit a compile-time error rather than a runtime error.
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.
Later stages use the name to disambiguate variables and this amgiguity
can lead to incorrect debug info that crashes LLVM. This also makes
the artificial variable names visible in textual SIL output.
rdar://82313550
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
Mangling uses a generic signature is used to shorten member types
to just a name where the protocol is unambiguous.
Unfortunately, in the particular case of 'associated type paths',
the IRGen mangler did not consistently set the right signature.
Sometimes, it would use no signature, and other times it would use
the signature of the concrete conforming type, which is incorrect
because the member type is written relative to the root protocol's
generic signature, <Self : P>.
This was caught by some new assertions I'm adding to the rewrite
system.
Note that this changes the mangling of a few symbols, but none
are public in the ABI.
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.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
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
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
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
