In #74516 the `SWIFT_NOEXCEPT` specifier is added to the imported Swift
functions in C++ mode, but it is added after the function attributes. It seems
that the tests only do `-fsyntax-only`, which seems not to catch an error like
"expected function body after function declarator" when the header is
used without that flag.
Flip the attributes and the specifier around in the printer, and flip
them in all the tests.
The tests were using `%check-in-clang`, but it only checks importing as
an objective-c-header. Add a parallel `%check-in-clang-cxx` to test also
in C++. It uses C++17 because of some details in the imported headers and
disables a warning about variadic macros that was promoted to an error
and was blocking passing the tests. The clang-importer-sdk gets the
minimal set of files to compile the two modified tests as C++. The files
are mostly empty, except `cstddef` that imports the equivalent C header.
Some modifications were needed in `ctypes.h` because the header was
using features only available in C and not C++.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Fix a leak when emitting the native to foreign thunk for an async
function which fulfills an Objective-C protocol requirement which can be
fulfilled with either a value or an error via a nullable completion.
Previously, the SIL in question used to look like this:
```sil
%maybe_completion = ...
try_apply %impl..., normal success, ...
success(%value):
switch_enum %maybe_completion...
case some!enumelt: invoke
case none!enumelt: ignore
ignore:
br join
invoke(%completion):
%some_value = enum Optional, some!enumelt, %value // consumes %value
%guaranteed_some_value = begin_borrow %some_value
%none_error = enum Optional, none!enumelt
apply %completion(%guaranteed_some_value, %none_error)
end_borrow %guaranteed_some_value
destroy_value %some_value
br join
join:
destroy_value %maybe_completion
...
```
which leaks %value on the codepath through `ignore`.
Note that `%value` is consumed by the `enum` instruction, but
`%completion` is invoked with `%guaranteed_some_value`, a guaranteed
value. So there is no need to consume %value in `invoke`.
Here, `%value` itself is borrowed and forwarded into an enum instruction
whose result is passed to `%completion`:
```sil
%maybe_completion = ...
try_apply %impl..., normal success, ...
success(%value):
switch_enum %maybe_completion...
case some!enumelt: invoke
case none!enumelt: ignore
ignore:
br join
invoke(%completion):
%guaranteed_value = begin_borrow %value
%guaranteed_some_value = enum Optional, some!enumelt, %guaranteed_value
%none_error = enum Optional, none!enumelt
apply %completion(%guaranteed_some_value, %none_error)
end_borrow %guaranteed_some_value
br join
join:
destroy_value %maybe_completion
destroy_value %value
...
```
Because an argument scope was already being created and a cleanup was
already being pushed for `%value`, nothing more is required to fix the
issue than to reorder the enum and the borrow.
rdar://119732084
For an isolated ObjC function that is not async, we
emit a hops around the call. But if that function
returns an autoreleased pointer, we need to ensure
we're retaining that pointer before hopping back
after the call. We weren't doing that in the case
of an autoreleased NSError:
```
%10 = alloc_stack $@sil_unmanaged Optional<NSError>
%19 = ... a bunch of steps to wrap up %10 ...
%20 = enum $Optional<AutoreleasingUnsafeMutablePointer<Optional<NSError>>>, #Optional.some!enumelt, %19 : $AutoreleasingUnsafeMutablePointer<Optional<NSError>>
hop_to_executor $MainActor
%26 = apply X(Y, %20) : $@convention(objc_method) (NSObject, Optional<AutoreleasingUnsafeMutablePointer<Optional<NSError>>>) -> @autoreleased Optional<NSString>
hop_to_executor $Optional<Builtin.Executor>
// retain the autoreleased pointer written-out.
%28 = load [trivial] %10 : $*@sil_unmanaged Optional<NSError>
%29 = unmanaged_to_ref %28 : $@sil_unmanaged Optional<NSError> to $Optional<NSError>
%30 = copy_value %29 : $Optional<NSError>
assign %31 to %7 : $*Optional<NSError>
```
This patch sinks the hop emission after the call
so it happens after doing that copy.
rdar://114049646
Swift names provided via C attributes or API notes can be parsed as
special names, such as `init` or `subscript`. However, doing so would
cause the Clang importer to crash, because it assumes that these names
are always identifiers. In these places, we actually want to treat
them as identifiers, where special names are mapped back to their
keywords. Introduce a function to do that, and use it consistently.
Swift has some module maps it overlays on Linux and Windows that groups all of the C standard library headers into a single module. This doesn’t allow clang and C++ headers to layer properly with the OS/SDK modules. clang will set -fbuiltin-headers-in-system-modules as necessary for Apple SDKs, but Swift will need to pass that flag itself when required by its module maps.
Swift 5 mode.
When you annotate a ValueDecl with `@preconcurrency`, the compiler should allow
concurrency violations by downgrading errors in the actor isolation checker to
warnings in Swift 5 mode. Previously, the actor isolation checker only checked
whether the caller's context was preconcurrency when deciding to downgrade, so
referencing preconcurrency declarations directly remained errors. Preconcurrency
was also dropped when computing actor isolation for declarations imported from
clang, which are always preconcurrency.
Clang Importer strips prefixes from enum and option set case names. The logic to do this computes a common prefix from the type name and all non-deprecated case names (to oversimplify), which means that adding, removing, or changing one case can change the prefix that is removed from *all* cases. This typically causes the prefix to become shorter, meaning that additional words are prepended to each existing case name.
Existing diagnostics make it look like the case has disappeared, when in fact it still exists under a different name. A little more information may help developers to figure out what happened.
Add a tailored diagnostic for this scenario which kicks in when (a) a missing member is diagnosed, (b) the base is an imported enum or option set’s metatype, and (c) an enum case or static property exists which has the name we attempted to look up as a suffix.
Fixes rdar://116251319.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Clang is no longer allowing function prototypes to leave out return types (see 2cb2cd242c). Fix a test header that does this for no particularly good reason.
Part of rdar://113413583.
The `isBoolType` operation within the Clang importer has a historical
definition that excludes the C++ `bool` and its use in C as an
extension. Retain that definition, and check for the actual `bool`
when importing C++ conversion functions into Swift.
Fixes two regressions in the Clang importer:
1. We started to import `bool`-typed Objective-C properties with their
getter names.
2. We started importing `bool`-typed Objective-C methods with an
NSError** parameter as `throws`.
Both of these changes could be considered improvements, but they
cannot be made without breaking source compatibility, so roll those
changes back to maintain source compatibility.
We should have a separate discussion about enabling this behavior for
Swift >= 6.
In order to allow supporting `__strong` (and `__weak`) struct fields,
some parts of the ClangImporter needs to understand them. The changes in
this commit allows the type importer to allow the already supported
`__unsafe_unretained` struct fields, but still reject the `__strong` and
`__weak` fields. Later changes will add support for bridging `__strong`
and `__weak` fields.
All the code should be equivalent to the previous code, and since all
the structs with non-trivial copy/destroy are completely discarded, the
code should not even be hit in any case.
The included modifications in the tests check that the error and the
diagnostics note are produced correctly.
A member reference to a function with a dynamic 'Self' result type
can introduce a covariant return expression into the AST. This is
exposed by the (already deeply cursed) -self method on NSObject(Protocol).
Add a regression test and said cursed member to the mock SDK.
when two objc async functions are composed with each other,
i.e., f(g()), then the clean-ups for g() would get emitted
at an unexpected time, namely, during the suspension for
the call to f(). This means that using a clean-up to emit
the executor-hop breadcrumb was incorrect. The hop could
appear between a get_async continuation and its matching
await_continuation, which is an unsupported nested suspension.
This commit fixes that by removing the use of the breadcrumb
clean-up in favor of providing that breadcrumb directly to
the result plan, so that it may be emitted later on when the
result plan sees fit.
Fixes rdar://91502776
In C, one can provide a typedef name for an anonymous tag declaration in
one shot, e.g.,
typedef struct {
double x, y
} Point;
In this case, there are effectively two declarations at the C level:
the typedef and the struct. The Clang importer was only taking
attributes from the anonymous struct (i.e., the tag) and not from the
typedef. However, any attributes put before the `typedef` should apply
as well... so consider those, too.
For now, only do this for `swift_attr` attributes, because we're
seeing this primarily with `Sendable` annotations. In the future, we
can look to generalizing it, but that could have source-breaking
consequences.
Fixes rdar://91632960.
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.
