-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[cxx-interop] Only swiftify template instantiations behind type aliases #81973
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
cdb813d
to
b1b29ce
Compare
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.
Actually, I just realised something: what happens if other parameters in the parameter list have un-typedef'd templates? I think we need to check that any template type in the signature is hidden behind a typedef
53f1207
to
4a08305
Compare
Good point, updated the PR. |
While I could not trigger a scenario where the generated macro triggers a compilation error, the generated code is definitely not valid Swift. rdar://151422108
4a08305
to
868c85d
Compare
@swift-ci please smoke test |
…aliases Explanation: C++ template instantiations that are not behind type aliases don't have corresponding Swift names that are both syntactically and semantically valid types. This PR prevents generating swiftified overloads for those types. Issue: rdar://151422108 Risk: Low, we swiftify functions less often. Testing: Regression test added. Original PR: #81973 Reviewer: @hnrklssn
…aliases Explanation: C++ template instantiations that are not behind type aliases don't have corresponding Swift names that are both syntactically and semantically valid types. This PR prevents generating swiftified overloads for those types. Issue: rdar://151422108 Risk: Low, we swiftify functions less often. Testing: Regression test added. Original PR: #81973 Reviewer: @hnrklssn
…aliases Explanation: C++ template instantiations that are not behind type aliases don't have corresponding Swift names that are both syntactically and semantically valid types. This PR prevents generating swiftified overloads for those types. Issue: rdar://151422108 Risk: Low, we swiftify functions less often. Testing: Regression test added. Original PR: #81973 Reviewer: @hnrklssn
While I could not trigger a scenario where the generated macro triggers a compilation error, the generated code is definitely not valid Swift.
rdar://151422108