This is an archive of the discontinued LLVM Phabricator instance.

[NFC][libc++] Removes concepts tests.
ClosedPublic

Authored by Mordante on Dec 23 2022, 9:11 AM.

Details

Reviewers
philnik
Group Reviewers
Restricted Project
Commits
rG1fd3173e02a7: [NFC][libc++] Removes concepts tests.
Summary

Concepts should be supported by all supported compilers. This is
probably a left over from an older version of the expected patch.

Diff Detail

Event Timeline

Mordante created this revision.Dec 23 2022, 9:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 23 2022, 9:11 AM
Mordante requested review of this revision.Dec 23 2022, 9:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 23 2022, 9:11 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik requested changes to this revision.Dec 23 2022, 9:14 AM
philnik added a subscriber: philnik.

No, not all compilers support P0848R3, which is required for the triviality.

This revision now requires changes to proceed.Dec 23 2022, 9:14 AM

No, not all compilers support P0848R3, which is required for the triviality.

Which compilers we support don't support this change? The CI is green https://buildkite.com/llvm-project/libcxx-ci/builds/16465

No, not all compilers support P0848R3, which is required for the triviality.

Which compilers we support don't support this change? The CI is green https://buildkite.com/llvm-project/libcxx-ci/builds/16465

Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.

Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.

See https://reviews.llvm.org/D128619; it's implemented, but there are still a large number of open concept issues so the feature macro hasn't been set.

Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.

See https://reviews.llvm.org/D128619; it's implemented, but there are still a large number of open concept issues so the feature macro hasn't been set.

That might be true, but this part seems to work. So I really would like to land this.
We normally don't use feature-test macros in our test, instead we define a helper macro which we use in the tests.
Since it works it makes little sense to add a helper macro to do the right thing.

philnik accepted this revision.Dec 30 2022, 5:38 AM

Clang trunk doesn't claim support: https://godbolt.org/z/hes3nah8s. I'm actually quite surprised this doesn't break the CI. I remember having problems with at least Clang 15 when trying to use conditionally trivial special member functions.

See https://reviews.llvm.org/D128619; it's implemented, but there are still a large number of open concept issues so the feature macro hasn't been set.

That might be true, but this part seems to work. So I really would like to land this.
We normally don't use feature-test macros in our test, instead we define a helper macro which we use in the tests.
Since it works it makes little sense to add a helper macro to do the right thing., s

I'm not a huge fan of enabling the tests when we know that the implementation is still incomplete and buggy (which is the reason the FTM hasn't been bumped yet). Though I guess we do that already in other places, so I guess this looks good to me. We should reconsider that position though IMO, since it results in workarounds where nobody knows in the end why they existed in the first place.

This revision is now accepted and ready to land.Dec 30 2022, 5:38 AM

That might be true, but this part seems to work. So I really would like to land this.
We normally don't use feature-test macros in our test, instead we define a helper macro which we use in the tests.
Since it works it makes little sense to add a helper macro to do the right thing., s

I'm not a huge fan of enabling the tests when we know that the implementation is still incomplete and buggy (which is the reason the FTM hasn't been bumped yet). Though I guess we do that already in other places, so I guess this looks good to me. We should reconsider that position though IMO, since it results in workarounds where nobody knows in the end why they existed in the first place.

I'm not against partly disabling tests when they don't work, but then we should use a libc++ specific test macro so we can enable/disable the feature based on our selection criteria. This is exactly how we have done it in the past, usually they were indeed based on a FTM but not always.

Thanks for the review!

This revision was automatically updated to reflect the committed changes.