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
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
This change fixes a swift-ide-test crash that occured in the Interop\Cxx\stdlib\msvcprt-module-interface.swift testcase with a newer MSVC, as one of its operator() had a parameter with a type that couldn't have been imported. The change ensures that body params are not used if they're null.
This fixes a crash in SILGen when calling a C++ subscript that has an unnamed parameter from Swift.
The parameters from a C++ `operator[]` get carried over to the synthesized Swift subscript. If the Swift parameter has no name, there is no way to refer to it in SIL. However, the synthesized subscript accessor needs to pass this parameter to C++.
This change makes sure that we give a name to the Swift parameter if there isn't already a name on the C++ side.
rdar://83163841
This allows calling a C++ function with default arguments from Swift without having to explicitly specify the values of all arguments.
rdar://103975014
Previously, `friend` operators declared in C++ classes were added to the lookup table when the class is being imported.
The operators were added to the wrong lookup table if the class is declared in a C++ namespace. Since a namespace can span across multiple Clang modules, its contents should be added to a translation unit level lookup table, not to a module level lookup table.
This change makes sure we add `friend` operators to the lookup table earlier, when we are actually building the lookup table. Note that this is not possible for class template instantiations, because those are instantiated later, so for templates we still handle `friend` operators when importing the instantiation.
rdar://116349899
If a C++ type `Derived` inherits from `Base` privately, the public methods from `Base` should not be callable on an instance of `Derived`. However, C++ supports exposing such methods via a using declaration: `using MyPrivateBase::myPublicMethod;`.
MSVC started using this feature for `std::optional` which means Swift doesn't correctly import `var pointee: Pointee` for instantiations of `std::optional` on Windows. This prevents the automatic conformance to `CxxOptional` from being synthesized.
rdar://114282353 / resolves https://github.com/apple/swift/issues/68068
When importing a C++ class template instantiation, Swift translates the template parameter type names from C++ into their Swift equivalent.
For instance, `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t>>` gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `wchar_t` is imported as `CWideChar`, which is a typealias for `Scalar` on most platforms including Darwin. Notice that Swift goes through the `CWideChar` typealias on the specific platform. Another instantiation `basic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>` also gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `uint32_t` is also imported as `Scalar`. This is problematic because we have two distinct C++ types that have the same name in Swift.
This change makes sure Swift doesn't go through typealiases when emitting names of template parameters, so `wchar_t` would now get printed as `CWideChar`, `int` would get printed as `CInt`, etc.
This also encourages clients to use the correct type (`CInt`, `CWideChar`, etc) instead of relying on platform-specific typealiases.
rdar://115673622
C++ `operator bool()` is currently imported into Swift as `__convertToBool()`, which shouldn't be used by clients directly.
This adds a new protocol into the C++ stdlib overlay: `CxxConvertibleToBool`, along with an intitializer for `Swift.Bool` taking an instance of `CxxConvertibleToBool`.
rdar://115074954
C++ `T& operator*()` is mapped to a Swift computed property `var pointee: T`.
Previously `var pointee` only had a getter, after this change it will also have a setter if the C++ type declares an overload of `operator*` that returns a mutable reference.
rdar://112471779
If a C++ struct defines multiple overloads of `operator*`, avoid synthesizing multiple `var pointee: Pointee` properties, since that would introduce name resolution ambiguity. Instead, pick one of the const overloads and synthesize a single `pointee` property.
This is required for `std::optional` support.
These operators return `Void` in Swift, let's drop the return type of these operators when importing them from C++.
This is needed for the upcoming `UnsafeCxxRandomAccessIterator` protocol: if a protocol declares `func +=` returning `Void`, but the implementation non-`Void`, that causes a typechecker error.
Prefix operators in Swift need to be marked as `prefix func`.
For example, the lack of `prefix` attribute prevents the user from conforming a C++ type that defines `operator!` to a Swift protocol that requires `static prefix func !(obj: Self) -> Self`.
C++ pre-increment operator `T& T::operator++()` is mapped into a non-mutating function `successor() -> Self`.
The naming matches existing functions for `UnsafePointer`/`UnsafeMutablePointer`.
The purpose of this is to be used for iterator bridging: C++ requires iterators to define a pre-increment operator (https://en.cppreference.com/w/cpp/named_req/Iterator), which Swift will use to iterate over C++ sequences and collections.
C++ iterator dereference operator is mapped to a Swift computed property called `pointee`.
For example:
```cpp
struct ConstIterator {
// ...
const int &operator*() const { /* ... */ }
};
```
is imported as
```swift
struct ConstIterator {
var pointee: Int32 { get }
@available(*, unavailable, message: "use .pointee property")
func __operatorStar() -> UnsafePointer<Int32>
}
```
This does not include subscript operators.
Before this is re-enabled operators need to be re-implemented. Right now they are the source of a lot of bugs. They cause frequent crashes and mis compiles. Also, templated operators insert a lot of names into global lookup which causes problems.
They also don't work on Windows.
Loading of the members of a C(++) struct/class can occur while doing a
direct lookup, so triggering a second direct lookup inside there can
introduce a request-evaluator cycle. Reimplement this operation to be
more like the way we lazily populate Objective-C classes and protocols,
walking through the record members in order and importing their
variants, then adding those. This eliminates a bunch of extraneous
lookup work, keeps the members in order (see the test case change),
and eliminates the potential for cycles.
If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
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.
This builds on top of the work of Egor Zhdan. It implements
`T operator[]` and does so largely by taking a path very much like the
`const T &operator[]` path.
This change adds support for calling `operator()` from Swift code.
As the C++ interop manifesto describes, `operator()` is imported into Swift as `callAsFunction`.
Adding integers is a commutative operation meaning the old tests would
fail to detect an error if the arguments were passed in the wrong order.
Testing inline member operators using subtraction ensures that arguments
are passed in the correct order.
This adds support to `ClangImporter` to import C++ member function operators as static methods into Swift, which is part of SR-12748.
The left-hand-side operand, which gets passed as the `this` pointer to the C++ function is represented as an additional first parameter in the Swift method. It gets mapped back in SILGen.
Two of the tests are disabled on Windows because we can't yet call member functions correctly on Windows (SR-13129).
