RFC: freestanding libc++ lit tests

Runtimes C++
1

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.

Recommendation:

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.

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.

Pros:

  • Clearly expresses separation between tests required for wg21 compliance and tests of vendor extensions

Cons:

  • Requires new lit features
  • Requires work on hosted tests to support freestanding (which is backwards)
  • Only alludes to freestanding rather than mentioning it directly

Alternative 1:
Use “UNSUPPORTED” instead of “REQUIRES”. Hosted tests would all get “UNSUPPORTED:freestanding”. Vendor extensions would be handled by deny-listing all the other freestanding platforms with libc++ support. For example, an extension in darwinKernel may say “UNSUPPORTED:winKernel,wellSupportedFreestandingPlatform2,wellSupportedFreestandingPlatform3”.

Pros:

  • Doesn’t require a new lit feature

  • Mention freestanding by name, rather than alluding to it via hosted
    Cons:

  • Scales poorly with the number of freestanding platforms available

  • Requires a lot of work from new platform authors

Alternative 2:
Add “negative features” to lit. If a lit configuration has a certain negative feature, then it will only run tests that mention that feature. For example, freestanding configurations would have the “freestanding” feature, and would only run tests that have the “TO_BE_DETERMINED: freestanding” annotation. lit configurations without the “freestanding” feature (i.e. hosted implementations) would still be able to run the test. I don’t see a good way to handle vendor extensions.

Pros:

  • Allow-lists just the freestanding tests
    Cons:

  • Requires a new lit feature

  • Doesn’t handle vendor extensions

2

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.

Recommendation:

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?
Louis

3

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.

4

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,
Louis

5

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