This is an archive of the discontinued LLVM Phabricator instance.

Generalize "check-all" umbrella targets, use for check-clang-tools
ClosedPublic

Authored by sammccall on Mar 16 2022, 11:52 AM.

Details

Summary

The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.

We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:

umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)

(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt

This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).

Diff Detail

Event Timeline

sammccall created this revision.Mar 16 2022, 11:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2022, 11:52 AM
sammccall requested review of this revision.Mar 16 2022, 11:52 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptMar 16 2022, 11:52 AM

This isn't ready for submission, there's some bits that touch the global variables in runtimes/, llvm/runtimes, and compiler-rt/test. Mostly to see the idea.

The main point is to allow check-clang-tools to cover the tests in clang-tools-extra without requiring them to be merged into a common test/ tree. (Thus enabling unmerging...)
It should also make it easy to add check-all targets to standalone builds of projects other than clang.

It probably makes sense to separate the behavior change for clang-tools-extra from the refactoring change to clang and llvm, combining them is mostly to make review clearer.

Fix LLVM_ADDITIONAL_TEST_{TARGETS,DEPENDS}

I think this is no longer [WIP] but rather review-ready, right?

Ran into problems caused by check-clang-tools not running clangd tests again, probably worth

I think this is no longer [WIP] but rather review-ready, right?

It's both WIP and review-ready :-)
There are some mechanical cleanups left to do as mentioned in the comment above, but there's no point doing them if the idea is wrong.

aaron.ballman retitled this revision from [WIP] Generalize "check-all" umbrella targets, use for check-clang-tools to Generalize "check-all" umbrella targets, use for check-clang-tools.Apr 6 2022, 9:08 AM

I think this is no longer [WIP] but rather review-ready, right?

It's both WIP and review-ready :-)
There are some mechanical cleanups left to do as mentioned in the comment above, but there's no point doing them if the idea is wrong.

I edited the title to remove the WIP bit so reviewers know. :-)

Can you rebase the patch so that precommit CI can go through the paces?

Can you elaborate more on the problem this is solving? Also, what are the user visible changes? Will check-all and check-clang run the same set of tests as before?

Can you elaborate more on the problem this is solving? Also, what are the user visible changes?

Most directly, check-clang-tools does not currently run clangd or clang-pseudo tests, but does after this patch.

More generally, it removes the requirement to intermingle the layout of projects (e.g. those under clang-tools-extra) that we want a single check-* target to cover.

Lit is a monolithic runner that expects to see all tests, manage parallelism and failures, and display interactive output.
This means if you want to run all tests in a subdirectory via e.g. ninja, you need to define a check-mydir target that knows about each lit test suite involved.

Examples of this pattern are:

  • check-clang-tools for llvm-project/clang-tools-extra/, today we force the tests of each project in this directory into a single test suite directory. (clangd/ and pseudo/ do not follow this, and so their tests are not run by check-clang-tools).
  • check-all for the llvm-project/ root, today we use global variables to keep track of all test suites. This is the mechanism this patch attempts to generalize.

Will check-all and check-clang run the same set of tests as before?

Yes, only check-clang-tools is intended to change.

sammccall updated this revision to Diff 421028.Apr 6 2022, 3:43 PM

rebased, come and get me robots

aaron.ballman accepted this revision.Apr 7 2022, 5:05 AM

I'm not an expert in CMake, but the changes look reasonable from what I do know. The current bot failures all look to be unrelated to the changes in this patch as best I can tell. Accepting, but you should probably wait for a second confirmation before landing.

This revision is now accepted and ready to land.Apr 7 2022, 5:05 AM
hokein added a comment.Apr 8 2022, 1:42 AM

+1, I think this is an improvement, it looks good overall, some nits.

clang-tools-extra/CMakeLists.txt
50

nit: remove the extra blank line.

clang/CMakeLists.txt
194–196

nit: add a # LLVM_INCLUDE_TESTS, this is a deeply-nested if statement, it would be easier to spot which if does the umbrella_lit_testsuite_begin stay.

llvm/cmake/modules/AddLLVM.cmake
1827

if I read the code correctly, input check-clangd the output is CLANGD, not CLANG.

1876

I don't know where is the name variable? it seems at this point we don't have a name var (unlike the code in the foreach(name ${gather_names}) below), I guess we probably should move it to the foreach?

LG to me with the comments that Haojian made!

llvm/cmake/modules/AddLLVM.cmake
1827

Also, maybe the other way around (-> check-clang) since it's a generic LLVM CMake module, not everyone here knows what clangd is.

sammccall updated this revision to Diff 423648.Apr 19 2022, 9:09 AM
sammccall marked 5 inline comments as done.

Update references to global test-tracking variables is compiler-rt, runtimes,
and llvm/runtimes.

Tested compiler-rt and runtimes standalone build.

Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptApr 19 2022, 9:09 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added subscribers: libcxx-commits, Restricted Project. · View Herald Transcript
This revision now requires review to proceed.Apr 19 2022, 9:09 AM
sammccall added inline comments.Apr 19 2022, 11:20 AM
llvm/cmake/modules/AddLLVM.cmake
1876

Wow, this was accidentally copied from line 1842. I suppose it was "mostly harmless". Removed.

sammccall added 1 blocking reviewer(s): ldionne.Apr 19 2022, 11:50 AM

The changes to runtimes/ are mostly mechanical, but Herald says I'm supposed to get a review :-)
@ldionne, @phosek, looks like this touches the same bits from D121276, WDYT?

ldionne resigned from this revision.Apr 24 2022, 9:29 AM

I think @phosek is the right person to look at this. I looked at it and it seems fine, but I don't know how the runtimes tests are setup well enough to spot an issue if there were one.

Nit: I'd suggest rebasing and re-uploading the patch so that the runtimes CI can run again (and hopefully pass -- there was a flake last time).

sammccall updated this revision to Diff 425995.Apr 29 2022, 2:19 AM

re-trigger CI

I think @phosek is the right person to look at this. I looked at it and it seems fine, but I don't know how the runtimes tests are setup well enough to spot an issue if there were one.

Nit: I'd suggest rebasing and re-uploading the patch so that the runtimes CI can run again (and hopefully pass -- there was a flake last time).

OK. I was requesting extra reviews because of the libc++ herald policy.
But since the changes are mechanical/cross-cutting, phosek isn't a libc++ approver, and there hasn't been more activity here I'm going to try to get this landed.

This revision was not accepted when it landed; it landed in state Needs Review.May 6 2022, 3:31 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Hi Sam, I've got a downstream build system that is failing here and I'm trying to figure out why.

After your commit, I get an error during bootstrapped runtime builds:

05-27 14:41 __main__     INFO     [202/796] cd /path/to/builddir/runtimes/runtimes-target-bins && cmake --build /path/to/builddir/runtimes/runtimes-target-bins/ --target runtimes-test-depends --config Release
05-27 14:41 __main__     INFO     ninja: error: unknown target 'runtimes-test-depends'

We have a mono-project CMakeLists.txt that builds our entire cross-compilation toolchain, libraries and all.
The build system uses a bootstrapping strategy, but must separate the builds of llvm/clang tools and the runtime builds, so we have LLVM_ENABLE_RUNTIMES set but LLVM_BUILD_RUNTIMES=OFF

Why do we do this instead of using the "default build strategy", you may ask? Well, the default strategy didn't exist when we set everything up. Wouldn't be against trying that if it seems to be the only way to fix the issue I'm seeing.

Specifically, in-order, the actions we perform:

  • Build clang/llvm tools (target llvm-build)
  • Build in-house tools
  • Build in-house C Library (uses just-built tools from above)
  • Build libc++, libc++abi, compiler-rt using llvm/runtimes (target 'runtimes'. Needs C includes and just-built compiler from previous step)
  • Build llvm-test-depends in preparation for check-all, etc. (arbitrarily ordered after runtime builds)

We do this by adding llvm as an ExternalProject and then adding step targets (llvm-runtimes, llvm-test-depends) that just map to the LLVM equivalent target.

I'll look more deeply into your commit and what's changed in our downstream build system, but I wanted to fire this comment off in case you've seen it or have a quick way to figure out what might be wrong.
We do have some downstream changes, including an abandoned commit (https://reviews.llvm.org/D72947) that could be causing issues. That's also a main target of scrutiny.

After some investigation, I found that we did not set LLVM_INCLUDE_TESTS from the top-level project. This seems like an oversight because we build the test-depends (and check-all) regularly.
After seeing LLVM_INCLUDE_TESTS to ON, the builds worked.

This commit cleaned things up and exposed that mistake.

After some investigation, I found that we did not set LLVM_INCLUDE_TESTS from the top-level project. This seems like an oversight because we build the test-depends (and check-all) regularly.
After seeing LLVM_INCLUDE_TESTS to ON, the builds worked.

This commit cleaned things up and exposed that mistake.

Sorry, this was a false positive. Building the 'test-depends' target still shows the LLVM build system telling the runtimes to build 'runtimes-test-depends', which is not defined in those ExternalProjects.