First time contributor, adding p1004 for C++20 -- constexpr std::vector

[Jonathan Wakely]

On 30/07/20 21:50 -0400, Josh Marshall wrote:
>I'm looking at the few hundred tests built up.  Would it be prudent
>for me to replicate all of these in a constinit/constexpr context?  Or

It's probably not efficient to just duplicate every test. Many of them
are for specific bugs that were present at one time and are now fixed.
In most cases, if the code is now fixed for the runtime case it should
also be correct for the compile-time case.

What's necessary is verifying that every code path works in constexpr
contexts.

I would add a new constexpr.cc test under each sub-directory of
testsuite/23_containers/vector that tests the relevant subset of the
API. Start at the beginning: you can't test anything unless you've
constructed a vector, so start with the constructors.

Making the default constructor constexpr should be easy. Do that, then
write a test to verify it les, and constructs an empty vector (which
will require making one or both of empty() and size() constexpr too).

Test-Driven Development is probably prudent here. Write a test that
checks whether a particular feature can be used in a constant
expression, then make the necessary changes so that test passes. Keep
adding tests for each distinct behaviour of each member function.

If the standard says "if this, do that, else do that" then you'll want
to write tests for each case. Otherwise you can't be sure both
branches in the member function are usable in constant expressions.

>is there a smaller subset I should focus on?  How should I handle
>their failures since constexpr tests will fail at compile time instead
>of run time?

Please read and digest:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html
It will save you time in the long run.

The answer to your question can be found at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#tests.dg.examples
and by examining existing tests for constexpr functionality such as
testsuite/25_algorithms/for_each/constexpr.cc

The do-do directive is used to tell the testsuite driver whether a
test only needs to bee compiled or if it also needs to be linked+run.

dg-error denotes an expected error, the test will fail if that error
doesn't happen when compiling the test.