This patch is follow-up work from #78942 and imports non-public members,
which were previously not being imported. Those members can be accessed
in a Swift file blessed by the SWIFT_PRIVATE_FILEID annotation.
As a consequence of this patch, we are also now importing inherited members
that are inaccessible from the derived classes, because they were declared
private, or because they were inherited via nested private inheritance. We
import them anyway but mark them unavailable, for better diagnostics and to
(somewhat) simplify the import logic for inheritance.
Because non-public base class members are now imported too, this patch
inflames an existing issue where a 'using' declaration on an inherited member
with a synthesized name (e.g., operators) produces duplicate members, leading
to miscompilation (resulting in a runtime crash). This was not previously noticed
because a 'using' declaration on a public inherited member is not usually
necessary, but is a common way to expose otherwise non-public members.
This patch puts in a workaround to prevent this from affecting the behavior
of MSVC's std::optional implementation, which uses this pattern of 'using'
a private inherited member. That will be fixed in a follow-up patch.
Follow-up work is also needed to correctly diagnose ambiguous overloads
in cases of multiple inheritance, and to account for virtual inheritance.
rdar://137764620
This commit removes the guardrails in ImportDecl.cpp:SwiftDeclConverter
that prevent it from importing non-public C++ members. It also
accordingly adjusts all code that assumes generated Swift decls should
be public. This commit does not import non-public inherited members;
that needs its own follow-up patch.
Note that Swift enforces stricter invariants about access levels than C++.
For instance, public typealiases cannot be assigned private underlying types,
and public functions cannot take or return private types. Meanwhile,
both of these patterns are supported in C++, where exposing private types
from a class's public interface is considered feature. As far as I am aware,
Swift was already importing such private-containing public decls from C++
already, but I added a test suite, access inversion, that checks and
documents this scenario, to ensure that it doesn't trip any assertions.
While private and protected fields coming from C++ cannot be accessed from Swift, they can affect Swift typechecking.
For instance, the Swift typechecker mechanism that adds implicit `Sendable` conformances works by iterating over all of the struct's fields and checking whether all of them are `Sendable`. This logic was broken for C++ types with private fields, since they were never accounted for. This resulted in erroneous implicit `Sendable` confromances being added.
Same applies for `BitwiseCopyable`.
In addition to this, ClangImporter used to mistakenly mark all C++ structs that have private fields as types with unreferenceable storage, which hampered optimizations.
As a side effect of this change, we now also provide a better diagnostic when someone tries to access a private C++ field from Swift.
rdar://134430857
If the IR representation of a C++ function takes an `SRet` parameter instead of a return value, Swift needs to wrap the corresponding argument with `sret(...)` on call site.
This fixes SILOptimizer crashes on arm64.
rdar://92963081
When we look up a name directly, make sure we provide a scope, this is required when C++ interop is enabled.
This issue was exposed when we look up if an NSString is hashable. There is a special case for classes that inherit from NSObject, but we didn't see that, because we couldn't find NSObject (because lookup failed).
The Clang Importer when C++ interop is not enabled, disambigate an Obj-C
class and protocol that are named the same by appending `Protocol` to
the protocol. This was not happening when C++ interop was enabled, but
should also apply to Obj-C++ modules.
The fix is providing an starting scope for the search, which the C++
name lookup need to actually find the similarly named counterpart.
Includes a test to avoid this problem creeping in again, and locally it
did not break any other tests.
This change teaches ClangImporter to import C++ methods marked with `__attribute__((__swift_attr__("mutating")))` as mutating in Swift. This is useful, for example, when a method mutates `this` despite being `const` in C++ (e.g. via `const_cast`).
This change makes ClangImporter import some C++ member functions as non-mutating, given that they satisfy two requirements:
* the function itself is marked as `const`
* the parent struct doesn't contain any `mutable` members
`get` accessors of subscript operators are now also imported as non-mutating if the C++ `operator[]` satisfies the requirements above.
Fixes SR-12795.
If we have a C++ record decl that's invalid (because of a deleted
destructor or copy constructor), bail before we import any of its
members or cache the decl. This way, we don't accidentally import any
"nested" decls.
This patch adds support for custom C++ destructors. The most notable thing here, I think, is that this is the first place a struct type has a custom destructor. I suspect with more code we will expose a few places where optimization passes need to be fixed to account for this.
One of many patches to fix SR-12797.
It is not completely uncommon for a record to get imported while
importing it's members (for example, if the member points back to the
parent record). In this case, simply use the already-imported record.
This should improve performance but also prevent an error where a member
accidentally had two parents.
This patch also moves around some of the member import/add logic to
allow for the above "optimization."
The C++ interop modules require C++ support. Explicitly require C++ as
a feature when building these modules. This has no impact on the
changes as all the tests enable C++ already.
When we try to emit debug info from C++ types we crash because we can't deserialize them. This is a temporary fix to circumnavigate the crash before a real fix can be created.
Currently, trying to do this causes an assertion failure in SILGen, so the
corresponding line in the SILGen test is commented out.
See https://bugs.swift.org/browse/SR-12750
This imports const members of C++ structs/classes stored properties with
an inaccessible setter.
Note that in C++ there are ways to change the values of const members,
so we don't use `WriteImplKind::Immutable` storage.
Resolves: [SR-12463](https://bugs.swift.org/browse/SR-12463)
