This makes sure that whenever we emit `#if defined(__OBJC__)`, the matching `#endif` has a comment `// defined(__OBJC__)`.
This makes both testing and reading the header file easier.
This change just stages in a few new platform kinds, without fully adding
support for them yet.
- The `Swift` platform represents availability of the Swift runtime across all
platforms that support an ABI stable Swift runtime (see the pitch at
https://forums.swift.org/t/pitch-swift-runtime-availability/82742).
- The `anyAppleOS` platform is an experimental platform that represents all of
Apple's operating systems. This is intended to simplify writing availability
for Apple's platforms by taking advantage of the new unified OS versioning
system announced at WWDC 2025.
- The `DriverKit` platform corresponds to Apple DriverKit which is already
supported by LLVM.
This was always set to `true` except for USR mangling, where we already
have it set to `false` for IDE USRs. The other clients were:
- AutoDiff, which is just using the resulting string as a dictionary
key, so don't seem to have any preference.
- The ClangImporter, which always overrides `@_originallyDefinedIn`
anyway.
Unfortunately, I did not find an easy way to fix the warning so
suppressed it for now. But I don't think we care about those symbols
being duplicated across different shared libraries.
rdar://159879290
This supports both built-in vector types and the SIMDX<T> Swift types
that are used through type aliases like float3. These SIMD types are
passed via compatibility structs (with their valued memcpy-d into the
ABI compatible struct) as they have special ABI rules. E.g., a float3 is
not passed as float3, but as float4 on the ABI level.
Previously, we did not expose simd types from Swift to C++ (unless the
SIMD types were impoted from clang).
rdar://153218744
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
Reverse interop has logic that avoids emitting ambiguous overloads into the generated header. That logic did not apply for functions declared within Swift extensions. This meant that the generated C++ header would sometimes not compile.
rdar://158252800
These are the minimal changes to make the reverse interop header compile
when embedded Swift is used. Previously, the _SwiftStdlibCxxOverlay.h
and the generated interop header disagreed on the mangling of a symbol.
This is not sufficient yet to use the embedded Swift standard library from
reverse interop, there are some missing symbols while linking. But this
PR enables doing reverse interop without using the stdlib types like
swift::String in C++. Follow-up PRs will fix the rest of the issues.
rdar://154740225
These objects are behind typedefs and user code supposed to use the
typedef names. We already have some logic in place for Obj-C interop.
Reuse the same logic for C++ to use the correct names.
rdar://150453489
These types are passed around as reference counted pointers, so the
optional representation of them are nullable pointers. Previously, we
tried to wrap them in swift::Optional.
rdar://157667946
There was a hard to see misalignment between types accepted as
representable in C languages defined in `BuiltinMappedTypes.def` and
those with an associated C type name defined in `PrimitiveTypeMapping`.
While `BuiltinMappedTypes` looked through typealiases,
`PrimitiveTypeMapping` didn't and instead referred only to types by
their identifier. So even when both files defined the same types by
name, their underlying type were only partially handled. An affected
type was `Unicode.Scalar` which is the underlying type of `CWideChar`
and `CChar32`. `Unicode.Scalar` was accepted as a C representable type
but was not printed using a corresponding C type name, breaking the
generated compatibility header.
Another issue with the use of identifiers in the PrimitiveTypeMapping
logic was a limited support for nested types. It would track
`Unicode.Scalar` only as `Scalar`.
This change updates `PrimitiveTypeMapping` to keep track of TypeDecls
instead of identifiers and look through typealiases. This fixes the
issue with `Unicode.Scalar`, allowing it to be printed using the type
defined by an alias and avoid matching an unrelated Scalar. It should
also prevent future types behind typealiases to trigger this same kind
of misalignment.
rdar://157332446
Fix crash when printing references to Unicode.Scalar in the
compatibility header.
Unicode.Scalar should not be printed in the first place, it's a Swift
struct. It should either be considered non-representable or printed as a
C / Objective-C type if that's the intent.
rdar://157120538
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.
Functions or template instantiations with Obj-C types should always be
behind a macro to make sure the interop header compiles cleanly in C++.
rdar://152836730
In the reverse interop header we generated move constructors that call
abort at runtime. This is problematic for several reasons:
* In C++14 and below some of our own generated functions like _make
ended up calling the move constructor. Those are calling abort and
also trigger unreachable code warning in newer versions of Clang.
In C++17 and up it is fine due to the guaranteed copy elision.
* Type traits are fooled and think these types are movable. As a result,
libraries could generate calls to the aborting move ctor.
This PR removes the generation of move operations. As we generate copy
operations, the compiler will not declare or define the move operations
implicitly. Whenever the user goes out of their way and try to move an
object they will get a copy instead.
rdar://150793518
The generated header did not compile due to a bug that prevented us from
referencing the correct namespaces derived from the nominal type's name
(an extension does not have a name). Moreover, we did not generate
forward declarations for the members of the extensions for classes and
enums (but we did for structs). This change also removes a workaround
that emitted String::Index as _String_Index.
rdar://153221450
There are two main scenarios when printing a compatibility header that
references a @cdecl enum defined in Swift code. (1) When defined in the
same module as it's used we can print the definition normally and then
reference it. (2) When used in a different mode we need to print a
forward declaration before we can reference it.
This change adds printing the forward declaration and fix an issue where
the compiler would instead print an @include of the Swift module. The
import of the Swift module would work only in a local scenario where a
compatibility header and module would be generated under the same name.
However for a distributed frameworks we do not distribute the
compatibility header so this strategy doesn't work. Relying on a forward
declaration should be more reliable in all cases but clients may need to
import the other compatibility header explicitly.
Print @cdecl enums in the C section of the compatibility header. Use and
extend the macros to support C compiler clients.
The macro is adapted to the features supported by the client compiler.
It uses an Objective-C style macro with raw type when available and
fallbacks to a simple typedef for C compatibility.
Start printing `#include` for headers referenced from `@cdecl` function
signatures. This adds on top of the existing tiered imports. We already
print each module referenced from decls printed in the compatibility
header. Previously we printed mostly `@import` with an option to
fallback on a `#import`. This change adds a third fallback to `#include`
when the module is referenced from a `@cdecl` function signature. The
bridging header can also be imported in a similar way.
Add a block for C clients in the compatibility header. This block
contains only the `@cdecl` functions that are printed using only C
types.
This C block is printed above the Objective-C and C++ blocks as if we
add support for `@cdecl` types other languages should be able to
reference them in function signatures. Other languages block don't
duplicate printing the `@cdecl` functions either as they are already
accessible to them.
