[libcxx-dev] RFC: freestanding libc++ lit tests

Ben Craig via libcxx-dev libcxx-dev at lists.llvm.org
Wed Nov 18 14:26:43 PST 2020

The "gigantic patch" will probably be a few weeks out, but yes, I will absolutely try and get a small, representative patch first.

From: Louis Dionne <ldionne at apple.com>
Sent: Wednesday, November 18, 2020 3:27 PM
To: Ben Craig <ben.craig at ni.com>
Cc: libcxx-dev at lists.llvm.org; Stephan T. Lavavej <stl at exchange.microsoft.com>
Subject: [EXTERNAL] Re: RFC: freestanding libc++ lit tests

On Nov 17, 2020, at 20:21, Ben Craig <ben.craig at ni.com<mailto:ben.craig at ni.com>> wrote:

I think I like it.  I'll restate it to check for understanding.

As a first pass, I'll apply an "UNSUPPORTED: freestanding" to all the facilities that the standard lists as hosted.

As we identify areas of vendor extension, we will label that area in the negative.  For example, assume some crazy vendor had a freestanding platform that supported iostreams.  At that point, we would add a libcpp-has-no-iostreams feature.  We would then remove "UNSUPPORTED:freestanding" from the associated tests and add "UNSUPPORTED:libcpp-has-no-iostreams" in its place.

This would have the effect of temporarily breaking the tests of all the vendors that don't support iostreams on freestanding.  But that's fine, they can fix things by adding libcpp-has-no-iostreams to their feature list.  They could also be pleasantly surprised to discover that their platform happens to support iostreams.

I'm not thrilled with the double negative in "UNSUPPORTED:libcpp-has-no-iostreams", but the workflow gets the job done.

Yes, you understand correctly. However, we should actually aim to define `freestanding` as a conjunction of finer grained features. For example, we could add a new Lit parameter `--param freestanding=[True|False]`, and that would be equivalent to implicitly setting other parameters like `--param has-localization=False --param has-random_device=False`, etc. Those finer-grained parameters don't exist in Lit today, they are currently tied to libc++ and set automatically based on what we find in libc++'s __config_site, but it would be easy to separate them from libc++ and add official support for them in the test suite.

I imagine there's going to be pretty gigantic patches coming up. Can you please open up a small one so we can discuss the specifics before you modify the whole test suite? It'll save time for everyone.

Cheers and thanks for your interest in improving the test suite,

From: Louis Dionne <ldionne at apple.com<mailto:ldionne at apple.com>>
Sent: Tuesday, November 17, 2020 3:55 PM
To: Ben Craig <ben.craig at ni.com<mailto:ben.craig at ni.com>>
Cc: libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org> <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>; Stephan T. Lavavej <stl at exchange.microsoft.com<mailto:stl at exchange.microsoft.com>>
Subject: [EXTERNAL] Re: RFC: freestanding libc++ lit tests

On Nov 15, 2020, at 12:19, Ben Craig <ben.craig at ni.com<mailto:ben.craig at ni.com>> wrote:

I'd like to start annotating the libc++ lit tests to indicate which can run in freestanding vs. hosted, while also allowing for vendor extensions to freestanding.  I'm going to need to add a new feature to lit though.

Mark all the hosted tests as "REQUIRES: hosted".  Most platforms would have the "hosted" feature set automatically.  Freestanding tests would not have any new REQUIRES attribute added.

I would like an approach where we add the minimum number of REQUIRES. Instead, I think using UNSUPPORTED is better. The reason is that by default, when you're porting the test suite to a new platform, you just don't define any lit features, and ideally that enables the full test suite. You can then see what fails, and see what features you actually need to define.

If you're using `REQUIRES:`, then the majority of tests will be disabled by default, if you don't define any Lit features. Of course, both are logically equivalent, but I just find that using `UNSUPPORTED: freestanding` provides more ergonomics than `REQUIRES: hosted`.

To handle vendor extensions, things get a little more involved.  I would like to add a "REQUIRES_ONE" tag, so that we can put expressions like "REQUIRES_ONE: hosted, darwinKernel" and "REQUIRES_ONE: hosted, winKernel".  The expression would be satisfied so long as at least one of the listed features is present.

This can be handled with `// REQUIRES: hosted || darwinKernel`. Boolean expressions in REQUIRES work.

All that being said, my actual preference to handle freestanding is to add finer-grained features to describe features that are not available on a specific platform. These features are generic and not target specific. For example, I added a mode of libc++ for platforms that don't support localization, and added the corresponding libcpp-has-no-localization Lit feature. The nice part about this feature is that some platform that supports everything but localization can simply use that, however if another platform is more constrained, they can intersect such features by defining multiple ones: libcpp-has-no-localization, libcpp-has-no-threads, libcpp-has-no-random_device, etc.

I think that's the most extensible way of supporting this. And then, freestanding can simply be an alias of some specific set of Lit features, like no localization, no random device, no this, and no that.

What do you think?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20201118/6bd39341/attachment-0001.html>

More information about the libcxx-dev mailing list