-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Backport some fixes for C++ interop tests on 5.4 #37379
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 test Windows platform |
CC: @gottesmm @zoecarver |
The C++ interop modules require C++ support. Explicitly require C++ as a feature when building these modules. This has no impact on the changes as all the tests enable C++ already.
This synchronizes the C/C++ standard that Swift uses for the clang importer with the defaults of the clang compiler. The default for the C standard remains the same at `gnu11`. However, if clang was built with a different default C standard, that will be preferred. The default for the C++ standard is moved to C++14. Although this is a reduced version, it matches what the current clang compiler defaults to. Additionally, if the user built clang with a different C++ standard, that standard would be preferred. Although the C++ support is a bit more conservative, the idea is that we can be certain that the clang version fully supports this standard as it it the default version for clang. The test change made here replaces the use of `auto` type parameters to templates which is a C++17 feature. Reduce the example to a C++14 equivalent. The clang version seems to behave differently in preventing the synthesis of the constexpr value. This persists into the newer clang releases as well. This is reasonable as the value does not need to be exported necessarily and users will be able to materialize the value. We use the optimizer to ensure that the value is inlined. This also repairs the C++ interop tests on Windows with a newer C++ runtime from Microsoft.
Do not override the C++ standard explicitly when running the tests. This will eventually be useful in allowing tests to run against different C++ standards.
Restore the explicit C++ standard for these tests as the C++ compiler invocation on Darwin uses the system compiler rather than the just built clang, which may be sufficiently different to have different default standards. This will be cleaned up with the next change to introduce a new `%target-clangxx` to control the C++ standard.
@swift-ci please test Windows platform |
Hi @compnerd - can you fill out the PR description please? |
@airspeedswift, sure, done :) I wanted to make sure that the full set of fixes were incorporated first is all. |
@swift-ci please test |
Build failed |
Build failed |
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 LGTM. Thanks!!
@compnerd @zoecarver Are we still missing change from main branch? |
@shahmishal - its actually that I grabbed an extra change, just need to drop 52490b1f5506e58f2162391f67739e251f4459aa. |
This enables control over the C++ flags used during testing for the C++ interop from a single location rather than having to alter all the tests.
Add an convert to the new `target-swiftxx-frontend` substitution in lit to control the C++ interop enabling in Swift. This allows for a single site which will enable control of both an overridden standard (for testing multiple C++ standards) and simplify writing tests.
@swift-ci please test |
Build failed |
Seems like an unrelated flake on the Linux side. |
@swift-ci please test Linux platform |
Backport some changes from main, which should repair the tests for the 5.4 release branch. This should allow us to get the CI into a green state on Windows as well.