[libc++] Rename the 'libc++' Lit feature to 'llvm-libc++'

[ldionne]

Summary

This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.

[• Quuxplusone]

libcxx/test/std/utilities/function.objects/func.search/func.search.bmh/hash.pred.pass.cpp

10 ↗

(On Diff #376313)

Off-topic, but what on earth? Why does libc++'s test suite have test cases that are XFAILed on libc++?

libcxx/utils/libcxx/test/params.py

105

I don't really know the use-case here, but maybe consider whether you want to

• call the non-Apple case upstream-libc++ or trunk-libc++ instead of llvm-libc++
• have an umbrella libc++ feature which can be REQUIRE'd against, in addition to the finer-grained subfeatures. (This would let you avoid changing the test suite at all. Any day we can avoid introducing regexes into the test suite, is a good day.)

[ldionne]

Address review comments

[ldionne]

libcxx/test/std/utilities/function.objects/func.search/func.search.bmh/hash.pred.pass.cpp

10 ↗

(On Diff #376313)

It's a common misconception that this is only "libc++"'s test suite. The intent is for it to be a general C++ Standard Library conformance test suite, and for it to be usable by any implementation of the C++ Standard Library. Libc++ is merely one of those implementations, and arguably the one that makes the most use of the test suite.

But in reality, libstdc++ and msvc do use our test suite from time to time, too.

libcxx/utils/libcxx/test/params.py

105

call the non-Apple case upstream-libc++ or trunk-libc++ instead of llvm-libc++

Yeah, I considered a few names but: upstream-libc++ makes it look like there's a "downstream" libc++ (as in a fork of libc++), which is not the case. It's more that it's configured differently. trunk-libc++ introduces a notion of being at the top of HEAD, which isn't really what I want to convey. I think it makes sense to talk about LLVM libc++ as opposed to <vendor> libc++, kind of how we distinguish LLVM Clang and Apple Clang. In a way, LLVM can be seen as a "vendor" for the toolchain that is released on llvm.org.

have an umbrella libc++ feature which can be REQUIRE'd against, in addition to the finer-grained subfeatures. (This would let you avoid changing the test suite at all. Any day we can avoid introducing regexes into the test suite, is a good day.)

I thought about that too but then refrained from doing it because I thought to myself "we added support for regular expressions just for that, why not use it?". Maybe that was the wrong call. I'll add a top-level feature as you suggest.

[ldionne]

Try to poke CI

[ldionne]

Poke again

[ldionne]

Poke CI

[ldionne]

Poke CI.

libcxx/utils/libcxx/test/params.py

 #===----------------------------------------------------------------------===##
 #
 # Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 #
 #===----------------------------------------------------------------------===##
 
 from libcxx.test.dsl import *
 from libcxx.test.features import _isMSVC
+import re
 
 _warningFlags = [
   '-Werror',
   '-Wall',
   '-Wextra',
   '-Wshadow',
   '-Wundef',
   '-Wno-unused-command-line-argument',
DEFAULT_PARAMETERS = [
 
   Parameter(name='enable_rtti', choices=[True, False], type=bool, default=True,
             help="Whether to enable RTTI when compiling the test suite.",
             actions=lambda rtti: [] if rtti else [
               AddFeature('no-rtti'),
               AddCompileFlag('-fno-rtti')
             ]),
 
-  Parameter(name='stdlib', choices=['libc++', 'libstdc++', 'msvc'], type=str, default='libc++',
-            help="The C++ Standard Library implementation being tested.",
-            actions=lambda stdlib: [
-              AddFeature('stdlib={}'.format(stdlib))
-            ]),
+  Parameter(name='stdlib', choices=['llvm-libc++', 'libstdc++', 'msvc'], type=str, default='llvm-libc++',
+            help="""The C++ Standard Library implementation being tested.
+
+                 Note that this parameter can also be used to encode different 'flavors' of the same
+                 standard library, such as libc++ as shipped by a different vendor, if it has different
+                 properties worth testing.
+
+                 The Standard libraries currently supported are:
+                 - llvm-libc++: The 'upstream' libc++ as shipped with LLVM.
+                 - libstdc++: The GNU C++ library typically shipped with GCC.
+                 - msvc: The Microsoft implementation of the C++ Standard Library.
+                """,
+            actions=lambda stdlib: filter(None, [
+              AddFeature('stdlib={}'.format(stdlib)),
+              # Also add an umbrella feature 'stdlib=libc++' for all flavors of libc++, to simplify
+              # the test suite.
+              AddFeature('stdlib=libc++') if re.match('.+-libc\+\+', stdlib) else None
+            ])),
 
   Parameter(name='enable_warnings', choices=[True, False], type=bool, default=True,
             help="Whether to enable warnings when compiling the test suite.",
             actions=lambda warnings: [] if not warnings else [
               AddOptionalWarningFlag(w) for w in _warningFlags
             ]),
 
   Parameter(name='debug_level', choices=['', '0', '1'], type=str, default='',