libc++: constexpr std::string does not work (clang 17)

[q66]

The following code:

#include <string>

constexpr std::string foo{"XX"};

int main() {
}

should compile, but instead it fails with:

test.cc:3:23: error: constexpr variable 'foo' must be initialized by a constant expression
    3 | constexpr std::string foo{"XX"};
      |                       ^~~~~~~~~
test.cc:3:23: note: pointer to subobject of heap-allocated object is not a constant expression
/usr/bin/../include/c++/v1/__memory/allocator.h:112:38: note: heap allocation performed here
  112 |             return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
      |                                      ^
1 error generated.

I haven't been able to find anything about this being broken, and available resources list the functionality as available since 15.

This is a musl/libc++/compiler-rt environment, on x86_64 architecture, but probably should not matter. The libc++ has hardened mode on.

[casavaca]

std::string is constexpr since C++20. I just tried and it works fine.

clang++ -g --std=c++20 -nostdinc++ -nostdlib++ -isystem $CHECKOUT/llvm-project/build/include/c++/v1 -L $CHECKOUT/llvm-project/build/lib/ -Wl,-rpath,$CHECKOUT/llvm-project/build/lib/ -lc++ a.cc

[q66]

yes, i'm adding -std=c++20; the error message without is different:

q66@banana: /home/q66/cports$ c++ test.cc -o test -std=c++20
test.cc:3:23: error: constexpr variable 'foo' must be initialized by a constant expression
    3 | constexpr std::string foo{"XX"};
      |                       ^~~~~~~~~
test.cc:3:23: note: pointer to subobject of heap-allocated object is not a constant expression
/usr/bin/../include/c++/v1/__memory/allocator.h:112:38: note: heap allocation performed here
  112 |             return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
      |                                      ^
1 error generated.
q66@banana: /home/q66/cports$ c++ test.cc -o test           
test.cc:3:23: error: constexpr variable cannot have non-literal type 'const std::string' (aka 'const basic_string<char>')
    3 | constexpr std::string foo{"XX"};
      |                       ^
/usr/bin/../include/c++/v1/string:704:7: note: 'basic_string<char>' is not literal because it is not an aggregate and has no constexpr constructors other than copy or move constructors
  704 | class basic_string
      |       ^
1 error generated.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: q66 (q66)

The following code:

#include <string>

constexpr std::string foo{"XX"};

int main() {
}

should compile, but instead it fails with:

test.cc:3:23: error: constexpr variable 'foo' must be initialized by a constant expression
    3 | constexpr std::string foo{"XX"};
      |                       ^~~~~~~~~
test.cc:3:23: note: pointer to subobject of heap-allocated object is not a constant expression
/usr/bin/../include/c++/v1/__memory/allocator.h:112:38: note: heap allocation performed here
  112 |             return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
      |                                      ^
1 error generated.

I haven't been able to find anything about this being broken, and available resources list the functionality as available since 15.

This is a musl/libc++/compiler-rt environment, on x86_64 architecture, but probably should not matter. The libc++ has hardened mode on.

[frederick-vs-ja]

This is already fixed by #66576. However, the changes are not yet backported to the 17.x branch.

Also, this issue is not technically a bug, although it complicated the implementation and confused many users.
See also

• Just how constexpr is C++20’s std::string?
• constexpr std::string update

[q66]

ah, thanks for clarifying - the place where I ran into the issue was when using system libcxx to compile chromium, which uses it in this exact manner - and by default bundles its own libc++ from trunk

i was successfully able to build it with system libc++ after changing it to inline variable, but that needs an exit-time destructor (which is probably not much of an issue though as it always fits in SSO)