This is an archive of the discontinued LLVM Phabricator instance.

[clang] Support array placement new in constant expressions
AbandonedPublic

Authored by ldionne on Dec 1 2021, 12:44 PM.

Details

Summary

This is necessary for std::construct_at to work on arrays inside a
constant expression.

Diff Detail

Event Timeline

ldionne requested review of this revision.Dec 1 2021, 12:44 PM
ldionne created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptDec 1 2021, 12:44 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Gentle ping -- I suspect this may be too naive, but it's a start. It would be awesome to ship this in LLVM 14, since it would allow us to unblock libc++ work on a couple features.

I have no special knowledge of this. Seems like "it can't be that easy," but I don't know.

clang/test/SemaCXX/cxx2a-constexpr-dynalloc.cpp
138

I would think you ought to have the same species of test for the array case, also. Could probably be added right in here:

std::construct_at<int>(p + 2, 3);
bool good = p[0] + p[1] + p[2] == 6;
std::construct_at<int[3]>(p, 4, 5, 6);
bool also_good = p[0] + p[1] + p[2] == 15;

Also, it would be good to test the behavior of using T = int[]; new (&a) T{} with an incomplete type, unless that's already tested somewhere.
Also note this test is compile-only (since it expects errors), and so it would probably be a good idea to have some tests for the behavior/codegen, not just that it seems to be accepted silently by the compiler (and in the presence of other errors at that).

I have no special knowledge of this. Seems like "it can't be that easy," but I don't know.

I agree with this. I have a little knowledge of the constant evaluator, but not enough to know what is going on in this function. Presumably the rest of the array case is handled below for the 'nothrow' array case, so maybe it _IS_ that easy? But Richard implemented this back in 2019 without review or explanation here, so we won't have anything for context unless @rsmith can comment.

I'm tempted to try to get this into main "soon" so that this can hang out in ToT for a while before making it to clang-15. I DO think that the suggestions that @Quuxplusone made for new tests is a really good idea (and frankly, I'd like to see this with better test coverage), but otherwise I'm tempted to approve.

ldionne abandoned this revision.Sep 1 2023, 8:39 AM

I've run out of time to work on this. It's also not clear that it's supported by the Standard right now since there's a not-voted-yet LWG issue about it (http://wg21.link/LWG3436).

Abandoning. This isn't blocking libc++ anymore, too.

Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2023, 8:39 AM