-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[cxx-interop] Disambiguate template instantiations with SIMD parameters #76249
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
|
@swift-ci please smoke test |
Xazax-hun
left a comment
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.
LGTM!
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.
Nit: This is probably not performance critical code, but usually it is more efficient to use llvm::Twine to concat strings, like:
(Twine("foo") + "bar" + "baz").str();
Feel free to leave as is.
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.
Good catch, switched this to use Twine.
2d29a2a to
484a5af
Compare
|
@swift-ci please smoke test |
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.
I think with twine we might no longer need the to_string. But not 100% confident on that.
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.
It doesn't compile for me if I remove to_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.
Hmm, maybe it still needs a ctor like Twine("SIMD") + Twine(type->getNumElements()) + ...
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.
Yeah, I think I slightly prefer to_string over Twine(...) in this case, since that makes it explicit that we aren't e.g. constructing a string with a given capacity/size – something a std::string constructor would do 🙂
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
484a5af to
d19c9eb
Compare
|
@swift-ci please smoke test |
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>andstd::vector<simd::float4>would get the same Swift name, causing compiler errors down the road.rdar://134214091