This adds a new implementation of virtual method dispatch that handles reference types correctly.
Previously, for all C++ types an invocation of a virtual method would actually get dispatched statically. For value types this is expected and matches what C++ does because of slicing. For reference types, however, this is incorrect, we should do dynamic dispatch.
rdar://123852577
Windows logic for determining address-only type layout for a C++ type is now unified with other platforms.
However, this means that on Windows, a C++ type with a custom destructor, but a default copy constructor
is now loadable, even though it's non-trivial. Since Swift does not support such type operations at the
moment (it can't be yet destroyed), mark such type as unavailable in Swift instead, when building for
the Windows target.
This fixes the Windows miscompilation related to such types when they were passed indirectly to C++
functions even though they're actually passed directly.
If a templated C++ class declares an operator as a member function, and is instantiated using a typedef or a using-decl on the C++ side, it previously could not be conformed to a Swift protocol that requires the operator function despite matching signatures.
This was due to a Swift name lookup issue: operators, unlike regular member functions, are found by doing an unqualified lookup. Since C++ class template specializations and their members are not added to `SwiftLookupTable`, when doing qualified lookup members are searched by looking at all of the members of the specialization and choosing the ones with matching names. With unqualified lookup, we cannot rely on knowing the right specialization and need to search for all the operators in a given module.
This change adds synthesized operator thunks to `SwiftLookupTable` to make them discoverable by unqualified lookup.
Calling `StructDecl::lookupDirect` with an operator identifier (e.g. `==`) previously returned no results. This happened because the underlying C++ operator function was added to the lookup table with an underscored name (e.g. `__operatorEqualEqual`), and the synthesized function was not added to the lookup table at all. Lookup should find the synthesized decl, since that is what Swift code will call.
This fixes a typechecker error when trying to conform a C++ struct that defines an operator to a Swift protocol with an operator requirement (e.g. `Equatable`).
If a C++ method returns a pointer and is not annotated with `returns_nonnull`, ClangImporter imports its return type as implicitly unwrapped optional `UnsafePointer<T>!`. This happens, for example, for `begin()`/`end()` methods of C++ collection types.
We would like to be able to conform C++ collections to `Swift.Sequence`/`Swift.Collection`/... To make this work, we create Swift protocols that require `func begin() -> RawIterator` and `func end() -> RawIterator` where `RawIterator` is an associated type.
The problem is that currently if `RawIterator` is `UnsafePointer<T>?`, `begin()`/`end()` methods that return an implicitly unwrapped optional `UnsafePointer<T>!` won't satisfy the requirements. This change fixes that.
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
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
