This change is necessary to differentiate between C++ const and non-const types in Swift.
For instance, `const int` and `int` would both be printed as `CInt` in Swift.
After this change, `const int` is stored as `CInt_const`
Instead of adding opaque fields for the base subobjects this patch
introduces a recursive walk to add all the base fields to the generated
Swift struct.
rdar://126754931
Clang now includes concepts in the mangled names of C++ functions: 4b163e343c
This adjusts the test to verify that we don't transitively emit the symbols referenced from the requires expression. Those symbols shouldn't be emitted because they are not executed.
rdar://127263407
If a C++ `struct Base` declares a method with a Clang attribute that Swift is able to import, and `struct Derived` inherits from `Base`, the method should get cloned from `Base` to `Derived` with its attributes.
Previously we were only cloning one attribute at most due to a bug in `cloneImportedAttributes`. DeclAttributes is an intrusively linked list, and it was being made invalid while iterating over it: `otherDecl->getAttrs().add(attrs)` iterates over the list and calls `otherDecl->add(eachElement)`, which invalidates the iterator after the first iteration.
This fixes `Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift` by adjusting the expected function signature.
On rebranch, the actual signature is:
```
define linkonce_odr void @_ZN10HasMethods28nonConstPassThroughAsWrapperEi(ptr dead_on_unwind noalias writable sret(%struct.NonTrivialInWrapper) align 4 %agg.result, ptr noundef nonnull align 1 dereferenceable(1) %this, i32 noundef %a)
```
rdar://127263407
This fixes `Interop/Cxx/class/returns-large-class-irgen.swift` by adjusting the expected function signature.
On rebranch, the actual signature is:
```
define void @_Z21funcReturnsLargeClassv(ptr dead_on_unwind noalias writable sret(%struct.LargeClass) align 8 %agg.result)
```
rdar://127263407
This fixes a compiler crash when calling a templated C++ function with a parameter of type `ObjCBool` from Swift. The compiler now emits an error for this.
Previously the following would happen:
1. Swift starts to emit SILGen for a call expression `takeTAsConstRef(ObjCBool(true))`.
2. `takeTAsConstRef` is a templated C++ function, so Swift asks Clang to instantiate a `takeTAsConstRef` with a built-in Obj-C boolean type.
3. Swift gets an instantiated function template back that looks like this: `void takeTAsConstRef(_Bool t) { ... }`.
4. Swift's ClangImporter begins to import that instantiated function.
5. Since the parameter type is not spelled as `BOOL`, the parameter is not imported as `ObjCBool`. Instead, it's imported as regular Swift `Bool`.
6. Swift realizes that the types don't match (`ObjCBool` vs `Bool`), tries to apply any of the known implicit conversions, fails to do so, crashes.
rdar://130424969
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
A C++ record destructor that is called implicitly in the landing pad cleanup code of a constructor after a field is initialized might only be referenced there, so the Clang decl finder should pick it up when scanning the AST for interesting Decls that might have to be emitted into one LLVM IR module.
emitManagedParameter assumes the passed value has an address type and
calls forBorrowedAddressRValue when the parameter convention is
Indirect_In_Guaranteed.
Call forBorrowedObjectRValue instead when the type isn't an address
type.
rdar://130456931
In C interop mode, the return type of builtin functions like 'memcpy' from headers like 'string.h' drops any nullability
specifiers from their return type, and preserves it on the declared return type. Thus, in C
mode the imported return type of such functions is always optional. However, in C++ interop mode, the
return type of builtin functions can preseve the nullability specifiers on their return type,
and thus the imported return type of such functions can be non-optional, if the type is annotated with
`_Nonnull`. The difference between these two modes can break cross-module Swift serialization, as
Swift will no longer be able to resolve an x-ref such as 'memcpy' from a Swift module that uses
C interop, within a Swift context that uses C++ interop. In order to avoid the x-ref resolution
failure, normalize the return type's nullability for builtin functions in C++ interop mode, to
match the imported type in C interop mode.
This fixed an issue when using 'memcpy' from the Android NDK in a x-module context, like
between Foundation (that inlines it) and another user module.
These x-refs might not be resolvable using regular lookup from the 'std' module as they could be instantiated/synthesized
by the clang importer. Augment the lookup logic in that case to try clang importer lookup logic that is used during
the conformance to the C++ iterator protocol.
When emitting a native-to-foreign thunk, pass the thunk's result address parameter to the native function if both the thunk and the native function return their results indirectly and the thunk is not for an async function.
Also, remove an outdated assertion.
rdar://124501345
