These are split-file C++ tests, this is a problem for swift-syntax
because `.swift` tests get parsed for round-trip testing if
swift-syntax is located near swift.
(cherry picked from commit c019b669a1)
Swift started to explicitly forbid the instantiation of C++ function
templates with arbitrary types in #77430, because many types cause the
Swift compiler to crash. However, those checks prevented them from being
instantiated with Swift closures (which were previously fine), causing
a regression.
This patch relaxes the convertTemplateArgument() function to also allow
converting Swift function types, and adds some tests to make sure doing
so is fine.
This patch also does some cleanup of existing tests checking the
instantiation of various types, and adds testing for C function pointers
and Obj-C blocks.
rdar://148124104
(cherry picked from commit 284de98744)
Revert "Merge pull request #79707 from DougGregor/transparent-integer-conversions"
This reverts commit 9c2c4ea07f, reversing
changes made to 829e03c104.
While we expect our users to use type aliases for template
instantiations, there are some contexts when we import instantiations
without aliases. Unfortunately, in case of C++ span we generated a name
for the instantiation that cannot be a syntactically valid Swift type
due to unary negation appearing in the type name. This PR replaces the
unary negation with "Neg" in the type name and also fixed a bug that
ended up printing certain unsigned values as signed. Moreover, this PR
also fixes some other fallouts in the SwiftifyImport macro.
rdar://146833480
This patch changes the class template printer to disambiguate const-qualified template arguments by wrapping them with __cxxConst<>, rather than suffixing them with _const.
This is necessary to accommodate template arguments that aren't just identifiers (i.e., Foo<Int_const> is ok, but Foo<Bar<T>_const> and Foo<((Bar) -> Baz)_const> are not syntactically valid). With this patch, we would produce Foo<__cxxConst<Int>>, Foo<__cxxConst<Bar<T>>, and Foo<__cxxConst<((Bar) -> Baz)>> instead.
This patch also disambiguates volatile-qualified template arguments with __cxxVolatile<>, and changes the printing scheme for std::nullptr_t from nil to __cxxNullPtrT (since nil is not a syntactically valid type name).
rdar://143769901
Instantiating C++ function templates with Swift types is not currently supported, but the Swift compiler attempts to do so. Sometimes this leads to a compiler crash; other times it leads to a runtime crash. This patch turns those crashes into compiler errors.
At the call site of a C++ function template, the Swift compiler must convert Swift types deduced by the Swift type checker back into Clang types, which are then used to instantiate the C++ function template. Prior to this patch, this conversion was performed by ClangTypeConverter::convert(), which converts unsupported Swift types. This patch factors out some reusable parts of convert() and uses them in a new ClangTypeConverter::convertTemplateArgument() method that only converts supported template argument types. In the future, this method can be elaborated to support instantiating C++ templates with more types.
rdar://112692940
When importing C++ class template instantiations, Swift generates a type name for each instantiation. The generated names must be unique, since they are used for mangling.
If multiple different C++ types declare nested types with the same name, which are then used as template arguments, Swift was generating the same name for those template instantiations (e.g. `shared_ptr<Impl>` for different `Impl` types).
This change makes sure we use fully-qualified type names of template parameters when generating Swift type names for class template instantiations (e.g. `shared_ptr<MyNamespace.MyClass.Impl>`).
This fixes an assertion failure coming out of IRGen:
```
Assertion failed: (Buffer.empty() && "didn't claim all values out of buffer"), function ~ConstantInitBuilderBase, file ConstantInitBuilder.h, line 75.
```
rdar://141962480
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
This makes sure that different template instantiations of `std::tuple` get distinct Swift type names.
Similar to aa6804a3.
This also refactors `swift::importer::printClassTemplateSpecializationName` to follow a proper visitor pattern for the C++ template arguments.
rdar://139435937
When Swift imports C++ template class instantiations, it generates a human-readable Swift name for each instantiation.
Having name collisions causes multiple Swift type with the same name, which confuses the compiler.
`MyClass<int[]>` and `MyClass<long[]>` were both being imported as `MyClass<_>` into Swift. This patch fixes that:
* `MyClass<int[]>` is now imported as `MyClass<[CInt]>`
* `MyClass<int[123]>` is now imported as `MyClass<Vector<CInt, 123>>`
rdar://138921102
When converting a C++ class template instantiation name into Swift, we previously didn't account for possible SIMD types. Those types were printed as `_`. This meant that e.g. `std::vector<simd::float3>` and `std::vector<simd::float4>` would get the same Swift name, causing compiler errors down the road.
rdar://134214091
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`
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
The type bridging logic assumed that if a value of type `Swift.Bool` is passed to a Clang function as an argument, then the type of the parameter must be a Clang built-in type (usually `_Bool`). This is not always correct. For instance, the type might be a templated const reference.
rdar://125508505
This is required to make the compiler distinguish between instantiations of `std::function`.
Previously, when generating a Swift type name for a `std::function` instantiation, we would always emit `_` as the template parameter. If someone referenced two different instantiations of `std::function` in a Swift module, they would get mangled with the same name, triggering linker errors later.
rdar://103979602
This makes sure we are printing more than one level of C++ template specializations when emitting a Swift struct name.
For instance, `std::__wrap_iter<char*>` and `std::__wrap_iter<const char*>` are currently imported with the same name in Swift. This means the mangled string will be the same for these specializations, despite them being distinct types. This causes mangling errors.
rdar://117485399
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
Also, make the analogous change to apple/swift-driver#1372, which gets the
sanitizer tests working on Android again, and remove the lld_lto feature in the
tests, which is now unused.
Fixes https://github.com/apple/swift/issues/66326
This allows us to reneable Windows method tests. Note that Windows still has
a broken convention for non-trivial record with non-trivial destructor but
trivial copy-constructor, so classes in the methods.swift test need an explicit
copy constructor.
Fixes rdar://88391102
This fixes linker errors when there are multiple instantiations of a templated struct with numeric template parameters.
When mangling the name of a C++ template specialization, we currently ignore non-type templated parameters. This causes two different instantiations of the same templated type to have the same mangled name, triggering linker errors.
rdar://107757051
This code used to crash the compiler:
var s = std.string("hi")
s.append("foo")
`append` in this case resolves to a templated C++ method that accepts `std::string_view`, while we tried passing a Swift String to it as a parameter.
rdar://107018724
When determining whether a C++ method is safe to be imported, we look at its return type to see if it stores any pointers in its fields.
If the type is templated, we might not have its definition available yet. Unfortunately we cannot instantiate it on the spot, since the Clang AST would be read and written at the same time.
Let's stay on the safe side and treat such methods as unsafe.
rdar://107609381
