rewriteIntegerTypes unwrapped the outer (Self) -> ... curry layer for
any instance member, constructor, or static decl. SubscriptDecl
interface types are not curried this way (they are already
(Args) -> Element), so the strip overshot into the bare element type
and the subsequent getParams() dereferenced garbage.
Gate the unwrap on hasImplicitSelfDecl(), which is the precise
condition for having an outer Self curry layer.
rdar://177482177
If a smart pointer type had both T& and T* taking constructors, we had
no way to figure out which one to pick for bridging and failed to import
the type. This PR makes sure we handle those scenarios and also support
references in the bridging operations. Moreover, it also handles
overloading based on const-ness of the ptrs/references. And makes sure
we do not create bridging operations (for now) from rvalue references.
The PR also fixes an assertion failure for types derived from
SWIFT_REFCOUNTED_PTR annotated types.
The PR also extends the test cases with more tests for fields.
rdar://177334824
Swift gained native Int128 / UInt128 types in SE-0425, but the plumbing
for bridging them across the C/C++ boundary was incomplete. CInt128 and
CUnsignedInt128 were never added to CTypes.swift, even though
BuiltinMappedTypes.def has been mapping __int128 / unsigned __int128 to
those names since 2013. Without the typealiases, every C declaration
mentioning __int128 was silently dropped at import time.
This patch adds the CInt128 and CUInt128 type aliases to CTypes.swift
for forward interop, and also adds the Int128 -> __int128 mapping in
PrintAsClang and IRABIDetailsProvider for reverse interop.
rdar://177111210
When a newer toolchain (Swift >=6.2) is used with an older SDK whose
stdlib predates Swift 6.2, the Cxx module interface references
`Swift.Span` and `Swift.MutableSpan` which don't exist in the older
stdlib, causing build failures.
Guard individual declarations in the Cxx overlay that reference
`Span`/`MutableSpan` behind `#if canImport(Swift, _version: 6.2)`. The
guard wraps (rather than replaces) existing feature-based guards like
`$LifetimeDependence`, so both compiler capability and stdlib
availability are checked.
rdar://176312542
If a C++ method is not static, let's not allow changing its parent struct type to a different type, since the implicit `this` parameter would have an incompatible type.
This fixes an assertion that would previously fire for this scenario.
rdar://161208348
Previously, we would import operator bool() by simply renaming it to
__convertToBool() using NameImporter. When we had a struct with that
member, we would conform it to CxxConvertibleToBool, which would allow
Swift.Bool to be initialized via Bool(fromCxx:).
However, this conformance relies on importing operator bool() eagerly,
and didn't work reliably when operator bool() was inherited. (Part of
the reason is because our base method synthesis logic would only create
clang::CXXMethodDecls but logic elsewhere specifically expected a
clang::CXXConversionDecl.) We also weren't handling things like
const-ness etc. directly.
This patch instead synthesizes a shim method __convertToBool() that
calls the underlying operator bool() const, which we no longer import
directly. It follows the same "look up and import on demand" pattern as
other special synthesized members that wrap operators, like .pointee and
.successor() and .subscript.
rdar://170857484
The test in this PR is one of the slowest running tests that we have
because it rebuilds foundation and the standard library modules in a new
module cache directory. This PR attempts to speed this test up by making
only one of the 4 invocations do the rebuild from scratch. This is
sufficient for the FileCheck invocation to test if the expected files
are present.
Moreover, we disable this test for ASAN builds for now where this test was
reliably timing out. Since we have other tests importing foundation, the
overlay, and the C++ standard library, we should not lose code coverage
in ASAN builds.
rdar://176484441
`enum XYZ : char32_t` was triggering an assertion failure in the Swift compiler. Swift expects all underlying enum types to be `ExpressibleByBuiltinIntegerLiteral`. `char32_t` was imported as `Unicode.Scalar`, which doesn't conform.
This replaces `Unicode.Scalar` with `UInt32` whenever it is used as the underlying type of a C++ enum.
rdar://148336856 / resolves https://github.com/swiftlang/swift/issues/80436
The subscript synthesis path was not calling importAttributes on the
accessor thunks, so Clang attributes like __attribute__((deprecated))
on operator[] were silently dropped. Import them onto the getter/setter
AccessorDecls, matching what the ObjC subscript import path does.
The implementation for this behavior was added in a previous patch;
this patch integrates and removes unused call sites.
This patch also adds some tests exercising the overloading behavior.
Annoyingly, imported members that point to the same source location
aren't sorted correctly in the module interface, so this changes the
order in a bunch of module interface tests.
rdar://170857428
Also, un-comment broken test case of using Base::operator[], which is
fixed by this commit.
rdar://145345345
When generating C++ interop headers with
-experimental-skip-non-exportable-decls, a deprecated method's
@available(*, renamed:) target may not pass shouldInclude(), e.g.,
because the target uses `throws` or types that otherwise can't be
exposed to C++.
Instead of asserting, fall through to print the raw rename string from
the attribute (same behavior as when getRenamedDecl() returns null).
rdar://151425131
We used unowned calling convention for all trivial C++ types, as a
result the move checker never diagnosed when an unintentional copy is
happened through a call. This PR changes move only types to use @owned
calling convention, matching what we do for native Swift types.
Now, we can no longer get away with these copies! Unfortunately, the fix
for now is turned off for types with the "destroy" attribute because the
synthesized code is triggering some errors. This can be fixed as a
follow-up.
rdar://135615824
When targeting Embedded Swift and using reverse C++ interop to generate a C++ interface for a Swift module, the compiler was emitting mangled names of Swift stdlib symbols that began with `$s`. This is incorrect in Embedded Swift: the mangling uses `$e` as the prefix.
Swift was also emitting references to Foundation symbols which are not available in Embedded Swift. This change removes those references.
rdar://154738972
Reproducer for a cycle warning during iterator conformance derivation.
The cycle requires three structural properties:
1. A class-template iterator with a free-function operator==
2. An unrelated nested class with a member operator==
3. The nested class's parent has a field of a different specialization
of the same iterator template
When all three are present, a module-wide operator== scan during
conformance derivation for one specialization can re-enter a mid-import
context for the other, triggering a cycle warning.
C++ types that are non-copyable and non-movable are not imported into Swift.
Variables of such types are marked as invalid in Swift by ClangImporter, however, compilation still proceeds without emitting any errors, unless the user attempts to use the problematic type from Swift. This differs from pure-Swift where having invalid decls are not allowed.
This adjusts the typechecker to account for the fact that a declaration coming from Clang might be invalid and not diagnosed at the same time. Instead of crashing in SILGen, let's emit a typechecking error.
rdar://137880350
Adds support for making pointers to C structs always import as OpaquePointer through API notes. This is needed to bring down the Android SDK to API level 23, since FILE is imported differently on API 23 vs 24.
When the swift compiler is built with ASAN, the standard library is also
built with ASAN. As a result, test executables will also load the ASAN
runtime. The failing test tried to load TSAN but having both at the same
time is not supported. This resulted in a failed test. Let's just not
run this test for ASAN builds.
rdar://175373146
This test started failing after swiftifyImpl was made more lazy in
importing return types, resulting in availability attributes not being
added before AST printing. We should fix this, but that's out of scope
for this PR. The availability attributes are still added if the user
tries to call the function, as that forces the return type import.
Macro expansions in this test trigger warnings, because the listed Span
availability is wider than that of the FRT parameters. This also
triggers an assert since these functions are imported with 2 overloads
that both get macro expansions with warnings in them: one for the free
function, and one for the function re-mapped to a method. Since -verify
disambiguates expansions solely on source location, this use case is not
supported. Having 2 expansions share a source location is okay under
-verify, as long as they don't both have diagnostics emitted.
These diagnostics are only emitted with -eager-macro-checking enabled,
since decls in clang modules are not normally typechecked by the Swift
compiler. The warning could be fixed by adding availability to imported
Swift function when they reference FRTs, but since it's not user
visible, silence it for now.
Normally macro expansions are typechecked through the normal traversal
of the AST. This does not happen with macro expansions in clang modules
however, since the clang module is not traversed by the typechecker.
This is not too problematic, since all the code in clang modules is
generated by the toolchain, so incorrect code would only occur when
there's a bug in the toolchain. Catching these bugs would be a lot
easier if we actually ran the typechecker during testing. We don't want
to do this normally, as it breaks the laziness of the typechecking, so
this adds -eager-macro-checking to specifically enable this behavior.
It's intended for testing purposes only.
We previously prevented generating safe wrappers on functions with
template instantiations in the signature, unless those instantiations
were hidden behind a typedef. This is because those template
instantiations cannot be expressed in Swift syntax, so the macro
would expand to a function with invalid syntax.
For the std::span parameter itself however, that type is replaced with a
Swift Span in the safe wrapper, so it's not an issue in the type
signature. We would previously use the std::span type name from the
original signature to cast from Span to std::span, which does not work
with the raw std::span type. This uses `.init` instead when this is the
case, which avoids spelling out the type. When possible, we still use
the concrete type name, for clarity and by providing information we have
accessible the typechecker needs to do less work.
Resolves#86339
rdar://167712240
Namespaces are imported into the __ObjC module. As a result, when a
Swift module is serialized, it refers to the declarations in the __ObjC
namespace. However, during deserialization, these declarations are found
in their original C++ module. The first failure triggered a recovery
that populated the __ObjC module so subsequent lookups succeed.
This PR makes sure we do not consider a declaration from the __ObjC
module that was found in a different clang module problematic.
Fixes#82318
John Hui
Egor Zhdan
Gábor Horváth
susmonteiro
Gabor Horvath
Patryk Stefanski
Henrik G. Olsson
Mads Odgaard
Justice Adams
Henrik G. Olsson
Mishal Shah