The copy operation is getting merged, resulting in the addition of `_Tm`
to the end of the `_ZN31NonTrivialCopyAndCopyMoveAssignC2ERKS` symbol
causing this test to fail. Adding that case.
This patch splits the parameters going into the copy assignment from
`instance2` into `instance`.
Some builds of the compiler are emitting additional annotations on the
pointer.
The resulting parameters on Linux (on my box anyway) look like this:
`(%struct.NonTrivialCopyAndCopyMoveAssign* noundef nonnull align 4 dereferenceable(5) %2, %struct.NonTrivialCopyAndCopyMoveAssign* noundef nonnull align 4 dereferenceable(5) %4)`
These annotations look reasonable, but they don't show up on macOS.
I've added check-same to ensure that the parameter passing is still
happening while ignoring the additional annotations.
A record that's non trivia for purpose of calls, as defined in Itanium ABI is allowed to have non-trivial copy/move assignment operators, but it most not have non-trivial constructors or destructors. This change ensures that a C++ record with a non-trivial copy assignment operator but trivial other members can be passed/returned directly by value, so that the compiler can accept the returned value correctly when calling a C++ function.
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
C++ types that store pointers as fields are treated as unsafe in Swift. Types that store other types that in turn store pointers are also treated as unsafe.
Types that store raw C++ iterators are also treated as unsafe in Swift. However, a type that stores another type that stores a raw iterator was previously imported as safe. This change fixes that.
rdar://105493479
Trying to use members of C++ private base classes from Swift causes an assertion failure in ClangImporter:
```
<build dir>/swift/lib/swift/macosx/arm64/libcxxshim.h:2:66: error: cannot cast 'A' to its private base class 'B'
To __swift_interopStaticCast(From from) { return static_cast<To>(from); }
^
```
Such members should not be exposed.
rdar://103871000
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.
When importing a C++ struct that contains two methods that only differ in const-ness, we append `Mutating` to the name of the non-const method to make it possible to call from Swift unambiguously.
Unfortunately that logic was dependent on the order in which we import methods of a class: the `Mutating` suffix was added when another method with the same name was already imported.
This caused lookup failures, and the behavior was incorrect when the pair of methods return instances of an unsafe type: the const overload was renamed as `Unsafe` properly, but the non-const overload was not renamed.
Also, make some related changes, like updating a path in the Android doc, making sure the
`unknown` vendor is always used, and using `CPU` instead of `CODEGENERATOR`.
Even if a virtual method is not used directly from Swift, it might get emitted into the vtable, and in that case the IR for it should be emitted to avoid linker errors.
Fixes https://github.com/apple/swift/issues/61730.
These tests fail when run locally on Apple Silicon Macs because they specify `-target x86_64-apple-macosx10.9` instead of `%target-cpu-apple-macosx10.9`. Tests that have architecture specific output should require that architecture.
