[libcxx-dev] How to check for a feature-test macro

[Marshall Clow via libcxx-dev]

On Wed, Dec 5, 2018 at 5:21 PM Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, 4 Dec 2018 at 19:34, Marshall Clow via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> In the tests, we have the following usage:
>>
>> #if TEST_STD_VER > 14
>> # if !defined(__cpp_lib_filesystem)
>> #  error "__cpp_lib_filesystem is not defined"
>> # elif __cpp_lib_filesystem < 201703L
>> #  error "__cpp_lib_filesystem has an invalid value"
>> # endif
>> #endif
>>
>> I submit that that's non-portable, because some standard libraries may
>> not implement all the features (that's the point of the feature-test
>> macro), and this test should not fail.
>>
>
> Maybe this is lack of imagination on my part, but isn't a test failure for
> an unimplemented standard library feature exactly the desired behavior?
>

No. The test here is for the correct definition of the macro in question.
With the adoption of feature test macros, the committee has explicitly
sanctioned the idea of incomplete implementations.


>
>
>> In D55308, I am using the following form:
>>
>> #if TEST_STD_VER > 17
>>   LIBCPP_ASSERT(IS_DEFINED(__cpp_lib_char8_t)); // libc++ implements this
>> # if defined(__cpp_lib_char8_t)
>> #  if __cpp_lib_char8_t < 201811L
>> #   error "__cpp_lib_char8_t has an invalid value"
>> #  endif
>> # endif
>> #endif
>>
>> Basically it (unconditionally) checks that if the macro is defined, then
>> it has a sane value.
>> Additionally, since we know that libc++ defines this, we check that.
>>
>> An alternate formulation - w/o the `IS_DEFINED` trickery.
>>
>> #if TEST_STD_VER > 17
>> # if !defined(__cpp_lib_char8_t)
>>   LIBCPP_STATIC_ASSERT(false, "__cpp_lib_char8_t is not defined");
>> # else
>> #  if __cpp_lib_char8_t < 201811L
>> #   error "__cpp_lib_char8_t has an invalid value"
>> #  endif
>> # endif
>> #endif
>>
>> Comments welcome.
>>
>
> A standard library implementation that partially supports a feature may
> define the feature test macro to a value lower than the standard one. Your
> revised approach would reject that.
>

It would; I haven't considered that.


> There are two things that I think are reasonable:
>
> 1) Condition all your tests on the relevant feature test macros, and add
>
> LIBCPP_STATIC_ASSERT(__cpp_lib_char8_t >= 201811L, "libc++ should
> implement this");
>
> to make sure that libc++ in particular behaves as expected, or
>
> 2) Write tests that test for conformance: the feature test macros should
> be correct and the functionality should be available. That way a standard
> library implementation that fails to implement a feature (and doesn't
> advertise the feature via feature test macros) doesn't get an "all tests
> pass" despite not implementing all of the standard library.
>
> I'd lean towards option 2 myself, but maybe vendors of other stdlibs using
> the libc++ testsuite might have a different opinion.
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>

I'd rather avoid that; long-term test failures are not in anyones
best-interest.
It leads to people ignoring the test results "oh, yeah we always have test
failures"

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181206/4134cff2/attachment.html>