-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cxx-interop] Use more correct type names in C++ template parameters #68620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This unblocks #68240. |
@swift-ci please smoke test |
@swift-ci please test |
23fc265
to
856216d
Compare
@swift-ci please smoke test |
856216d
to
6cbdcaf
Compare
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
6cbdcaf
to
dae04e2
Compare
@swift-ci please smoke test |
dae04e2
to
c83df4f
Compare
@swift-ci please smoke test |
bcaa474
to
3fa512d
Compare
@swift-ci please smoke test |
3fa512d
to
eee38f0
Compare
@swift-ci please smoke test |
eee38f0
to
6f146a0
Compare
@swift-ci please smoke test |
6f146a0
to
f2e4832
Compare
@swift-ci please smoke test |
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
f2e4832
to
041005a
Compare
@swift-ci please smoke test |
@@ -2217,7 +2217,7 @@ ImportedName NameImporter::importNameImpl(const clang::NamedDecl *D, | |||
version, givenName); | |||
if (!isa<clang::ClassTemplatePartialSpecializationDecl>(D)) { | |||
auto getSwiftBuiltinTypeName = | |||
[&](const clang::BuiltinType *builtin) -> std::optional<StringRef> { | |||
[&](const clang::BuiltinType *builtin) -> std::optional<std::string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This dangling pointer issue got exposed by this patch
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 asbasic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>
:wchar_t
is imported asCWideChar
, which is a typealias forScalar
on most platforms including Darwin. Notice that Swift goes through theCWideChar
typealias on the specific platform. Another instantiationbasic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>
also gets imported asbasic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>
:uint32_t
is also imported asScalar
. 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 asCWideChar
,int
would get printed asCInt
, etc.This also encourages clients to use the correct type (
CInt
,CWideChar
, etc) instead of relying on platform-specific typealiases.rdar://115673622