We have been mangling extern "C" symbols when building with C++
interoperability, leading to incorrectly-mangled names such as
_Z6memset that should have been unmangled "memset". Fix this so we get
consistent mangling between C and C++ interoperability modes.
Fixes rdar://164495210.
Specifically, this means importing getters defined via swift_async_name. This
just ensures that they are treated just like any other imported objc async
function with completion handler.
rdar://156985950
A "permanently enabled" availability domain is one that has been declared
always available and is also simultaneously has either an attribute that
makes it deprecated or universally unavailable.
Emit fix-its that remove (or update) `@available` attributes that restrict
availability in a permanently enabled domain. Also, emit warnings about
`if #available` queries that always return true because they check a
permanently enabled domain.
Resolves rdar://157601761.
Declarations that are unavailable at runtime because of an `@available`
attribute referencing a custom domain that was imported `@_spiOnly` should be
hidden from public swiftinterface files in `-library-level=api` modules. For
remaining declarations that do get printed in the public swiftinterface, skip
printing any `@available` attribute that refers to the domains from those
`@_spiOnly` dependencies. This allows API developers to control declaration
visibility using availability defined by another module.
Resolves rdar://156512028.
Ttheir availability is going to match the property itself.
This is a workaround for lazy type-checking because synthesis
of accessors for such properties requires a reference to
`self` which won't be available because pattern binding
for the variable was skipped.
Resolves: rdar://129359362
Resolves: rdar://159463230
Resolves: https://github.com/swiftlang/swift/issues/84041
Teach Sema to diagnose the access level, exportability, and availability of
availability domains that are referenced by `@available` attributes and
`if #available` statements.
Resolves rdar://159147207.
When emitting statement diagnostics for `if #available` queries, diagnose the
availability of the decls representing the referenced availability domains.
Among other things, this checks that the domains are sufficiently visible to be
used in the containing function body context.
The bug tracked by rdar://158172056 was already fixed by
https://github.com/swiftlang/swift/pull/83607 but this additional test case is
needed to ensure that conformances to Obj-C protocols with obsolete
requirements imported under legacy spellings not regress again.
Specifically, I taught SILGen how to emit an AST like the following:
```
(force_value_expr implicit type="nonisolated(nonsending) (Date?) async -> Void" implicit_iuo_unwrap
(open_existential_expr implicit type="(nonisolated(nonsending) (Date?) async -> Void)?"
(opaque_value_expr implicit type="AnyObject")
(declref_expr type="AnyObject" decl="test.(file).repro().anyObject@test.swift:6:7" function_ref=unapplied)
(optional_evaluation_expr type="(nonisolated(nonsending) (Date?) async -> Void)?"
(inject_into_optional type="(nonisolated(nonsending) (Date?) async -> Void)?"
(function_conversion_expr type="nonisolated(nonsending) (Date?) async -> Void"
(bind_optional_expr type="(Date?) async -> Void" depth=0
(dynamic_member_ref_expr type="((Date?) async -> Void)?" decl="__ObjC.(file).Foo.start(at:)"
(opaque_value_expr type="AnyObject"))))))))
```
Since we are emitting an objc async function, there isn't an extra implicit
parameter like if we were using a swift async function. So, I just reused code
that was already used locally to look through these sorts of conversions. I
just had to add to that code support for conversions that add
nonisolated(nonsending). Previously it only supported looking through global
actor conversions.
rdar://152596823
This matches send non sendable but importantly also makes it clear that we are
talking about something that doesn't conform to the Sendable protocol which is
capitalized.
rdar://151802975
Due to a bug in how macros on nodes imported from clang are evaluated,
their function body is not always type checked. This forces type
checking before silgen of a macro originating on a node imported from
clang, to prevent crashing in silgen.
rdar://150940383
Both the syntax and relative order of the LLVM `nocapture` parameter
attribute changed upstream in 29441e4f5fa5f5c7709f7cf180815ba97f611297.
To reduce conflicts with rebranch, adjust FileCheck patterns to expect
both syntaxes and orders anywhere the presence of the attribute is not
critical to the test. These changes are temporary and will be cleaned
up once rebranch is merged into main.
Some notes:
1. In most cases, I think we were getting lucky with this by just inferring the
closure's isolation from its decl context. In the specific case that we were
looking at here, this was not true since we are returning from an @concurrent
async function a nonisolated(nonsending) method that closes over self. This
occurs since even when NonisolatedNonsendingByDefault we want to start importing
objc async functions as nonisolated(nonsending).
2. I also discovered that in the ActorIsolationChecker we were not visiting the
inner autoclosure meaning that we never set the ActorIsolation field on the
closure. After some discussion with @xedin about potentially visiting the
function in the ActorIsolationChecker, we came to the conclusion that this was
likely to result in source stability changes. So we put in a targeted fix just
for autoclosures in this specific case by setting their actor isolation in the
type checker.
3. Beyond adding tests to objc_async_from_swift to make sure that when
NonisolatedNonsendingByDefault is disabled we do the right thing, I noticed that
we did not have any tests that actually tested the behavior around
objc_async_from_swift when NonisolatedNonsendingByDefault is enabled. So I added
the relevant test lines so we can be sure that we get correct behavior in such a
case.
rdar://150209093
This attribute was introduced in
7eca38ce76d5d1915f4ab7e665964062c0b37697 (llvm-project).
Match it using a wildcard regex, since it is not relevant to these
tests.
This is intended to reduce future conflicts with rebranch.
When serializing `@available` attributes, if the attribute applies to a custom
domain include enough information to deserialize the reference to that domain.
Resolves rdar://138441265.
Consider code like:
```
// Foo.h
typealias NSString * FooKey NS_EXTENSIBLE_TYPED_ENUM;
// Foo.swift
extension FooKey { … }
```
When Swift binds the extension to `FooKey`, that forces ClangImporter to import `FooKey`. ClangImporter’s newtype logic, among other things, checks whether the underlying type (`Swift.String` here) is Objective-C bridgeable and, if so, makes `FooKey` bridgeable too.
But what happens if this code is actually *in* Foundation, which is where the `extension String: _ObjectiveCBridgeable` lives? Well, if the compiler has already bound that extension, it works fine…but if it hasn’t, `FooKey` ends up unbridgeable, which can cause both type checking failures and IRGen crashes when code tries to use its bridging capabilities. And these symptoms are sensitive to precise details of the order Swift happens to bind extensions in, so e.g. adding empty files to the project can make the bug appear or disappear. Spooky.
Add a narrow hack to ClangImporter (only active for types in Foundation) to *assume* that `String` is bridgeable even if the extension declaring this hasn’t been bound yet.
Fixes rdar://142693093.
Since we can't do a proper "deep" clone of expression nodes, cloning
such a CustomAttr is necessarily shallow. In such cases, don't cache
the swift_attr source files at all, so we get fresh attribute nodes
for each such usage.
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
https://github.com/swiftlang/swift/pull/77236 caused a source compatibility
regression because `extractEnumElement()` does not suppress its diagnostics in
the context of pattern matching. Potentially unavailable enum elements should
not be diagnosed when pattern matching since the generated code will not
retrieve the potentially unavailable element value on versions where it is
unavailable.
Fixes rdar://138771328.
These currently end up as "open", which is incorrect (we need to make them
"final"). This cannot be addressed until we pass the lexical context
down to the macro, which is currently... a bit tricky.
The Clang importer maps arbitrary attributes spelled with `swift_attr("...")`
over to Swift attributes, using the Swift parser to process those attributes.
Extend this mechanism to allow `swift_attr` to refer to an attached macro,
expanding that macro as needed.
When a macro is applied to an imported declaration, that declaration is
pretty-printed (from the C++ AST) to provide to the macro implementation.
There are a few games we need to place to resolve the macro, and a few more
to lazily perform pretty-printing and adjust source locations to get the
right information to the macro, but this demonstrates that we could
take this path.
As an example, we use this mechanism to add an `async` version of a C
function that delivers its result via completion handler, using the
`@AddAsync` example macro implementation from the swift-syntax
repository.
A change to the way we determined whether a protocol conformance is
"dependent" for marker protocols caused an ABI break for
Sendable-refining protocols built with pre-6.0 Swift compilers. The
fix for this issue (https://github.com/swiftlang/swift/pull/75769)
gated the change on deployment target.
The deployment target change fixed the original problem, then caused a
related issue when a project mixes deployment targets (pre-6.0 and
6.0+) with non-resilient protocols. Exempt non-resilient protocols from
this change so we get consistent behavior.
Fixes rdar://134953989.
Honour the SDK for APINotes to augment the system libraries. This allows
us to distribute APINotes with the Swift SDK and impact the system
without having to map the APINotes into the filesystem.
Print an error message and exit with a non-zero code when we hit the timeout. This makes it clear when a test fails due to a timeout. On Darwin, run `sample` on the target process first, so that the failure includes some information about what the test was doing when the timeout occurred.
If a function body is emitted, all of the declarations inside that function
body must be emitted, too. Previously, lazy var initializers were being skipped
regardless of whether the function containing them was skipped, resulting in
SIL verification errors (which were correctly predicting linker errors).
Resolves rdar://134708502.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
Within Swift 6.0, we expanded an optimization for witness tables that
that allowed direct access to the witness table for conformances to
any protocol that can never have a witness table, rather than requiring
access through `swift_getWitnessTable` that might need to instantiate
the witness table.
The previous optimization only covered Objective-C protocols, but Swift
6.0 expanded that to marker protocols (such as `Sendable`) as well.
However, this constituted an API break when a Swift 6.0 compiler uses
a witness table that comes from a library built with an earlier version
of Swift, when the protocol inherits from Sendable but the conformance
to that protocol otherwise does not require an instantiation function.
In such cases, Swift 6.0 would generate code that directly accesses
the uninstantiated witness table symbol, which will have NULL entries
for any conformance in it that was considered "dependent" by the
earlier Swift compiler.
Introduce a deployment target check to guard the new optimization.
Specifically, when building for a deployment target that predates
Swift 6.0, treat conformances to marker protocols as if they might be
dependent (so the access patterns go through `swift_getWitnessTable`
for potential instantiation on older platforms). For newer deployment
targets, use the more efficent direct access pattern.
Fixes rdar://133157093.
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++.
