This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Remove _LIBCPP_CONSTEXPR_AFTER_CXX17_WITH_IS_CONSTANT_EVALUATED
ClosedPublic

Authored by Quuxplusone on Nov 23 2020, 10:23 AM.

Details

Reviewers
ldionne
zoecarver
Group Reviewers
Restricted Project
Summary

Zoe Carver says: "We decided that libc++ only supports C++20 constexpr algorithms when is_constant_evaluated is also supported. Here's a link to the discussion."
https://reviews.llvm.org/D65721#inline-735682

After this patch, the following C++20 test case seems to work okay for me in all its configurations:

// clang++ -std=c++20 -DX=0 should work
// clang++ -std=c++20 -DX=1 should work
// clang++ -std=c++20 -DX=2 should work
// clang++ -std=c++20 -DX=3 should not work

#if X & 1
#define _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED
#endif

#include <algorithm>

constexpr int test() {
    int x[10] {};
    int y[10] {};
    std::copy(x, x+10, y);
    std::copy_n(x, 10, y);
    std::move(x, x+10, y);
    std::copy_backward(x, x+10, y+10);
    std::move_backward(x, x+10, y+10);
    return 0;
}

int main() {
#if X & 2
    constexpr int i = test();
#else
    const int i = test();
#endif
}

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2020, 10:23 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone requested review of this revision.Nov 23 2020, 10:23 AM

This could maybe be a different patch, and will likely be more difficult but now that we don't conditionally apply constexpr, we should remove all uses of _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED from the test suite and mark the compilers that fail as unsupported. We should really do this anyway to make the tests more portable.

@zoecarver: That seemed pretty simple, so I'm just gonna try it in this same patch. It looks like we expect clang-8 bots to fail (hopefully in buildkite pre-landing :)), and if they do fail, then we update this patch with something like Louis' 5911e6a8857f146fb5a8f23af1d768aba25e7c3e.

@zoecarver: That seemed pretty simple, so I'm just gonna try it in this same patch. It looks like we expect clang-8 bots to fail (hopefully in buildkite pre-landing :)), and if they do fail, then we update this patch with something like Louis' 5911e6a8857f146fb5a8f23af1d768aba25e7c3e.

Note that we don't have clang-8 bots in the pre-commit CI.

ldionne accepted this revision.Nov 23 2020, 1:39 PM

This LGTM. I do expect this is going to break some tests on slightly older compilers, so we should add some UNSUPPORTED markup. I think we can check this in, keep an eye on the post-commit Buildbots and see if anything fails, and then fix it quickly if so.

LGTM once the pre-commit CI passes.

This revision is now accepted and ready to land.Nov 23 2020, 1:39 PM
libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/move.pass.cpp
42

(commenting here just so we get nice comment threading)

Note that we don't have clang-8 bots in the pre-commit CI.
I do expect this is going to break some tests on slightly older compilers, so we should add some UNSUPPORTED markup. I think we can check this in, keep an eye on the post-commit Buildbots and see if anything fails, and then fix it quickly if so.

Aw, phooey. @ldionne, do you think it would make sense to preemptively // UNSUPPORTED: clang-8 on these char_traits tests I'm changing?

If you're expecting buildbot breakage, which likely @ldionne will be the one to fix and Arthur won't, then I suggest that @ldionne should be the one to land this patch. Or else Slack me so that we can both be paying attention at the same time. I just don't want to land it right before you go to sleep or something.

ldionne added inline comments.Nov 24 2020, 7:18 AM
libcxx/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/move.pass.cpp
42

Let's add UNSUPPORTED markup first. Then ping me on Slack and we'll land it. There shouldn't be failures because of the markup, but who knows.

This has been landed in ee95c7020cebe4668a501f24305a76a044df5266, but I forgot to put the "Differential Revision:" line in the commit message so it failed to get auto-closed.

This has been landed in ee95c7020cebe4668a501f24305a76a044df5266, but I forgot to put the "Differential Revision:" line in the commit message so it failed to get auto-closed.

If you upload patches with arc diff, the commit message is edited automatically.