All
I recently wanted to check something in clang-tidy, and so chose to run the
ninja check-clang-tools target to check the unit tests…(this may not be the correct target)
There seemed to be significant number of failures (80) especially in clang-change-namespace
Am I:
a) Running an invalid ninja target?
b) Perhaps these tests don’t run well on windows (my primary platform) and need fixing?
c) Are these tests run as part of any pre-merge tests?
d) Do any of the buildbots run these tests? (so I could check if its just my area!)
e) Is this code still relevant that one of us should try and fix them?
Many thanks in advance.
MyDeveloperDay.
a) That ninja target seems valid to me, at least one bot uses it.
b) I looked through the buildbot configs in
https://github.com/llvm/llvm-zorg and found at least one Windows bot
is running them.
In the "stage 1 check" you can see:
Running: ninja -j 32 check-llvm check-clang check-clang-tools
check-clangd check-lld
Pretty sure all of our (Linaro's) bots are running them on Linux, e.g.
Buildbot. It uses
check-all but you can see clang-tools-extra enabled in the cmake
command, which I think will add that target.
One thing to check is whether these tests are enabled with some other
option or dependency. For example, does cmake check that you've
installed a helper library before adding them and your system happens
to have it and the bot doesn't?
c) The buildkite premerge testing is configured with
https://github.com/google/llvm-premerge-checks/blob/main/scripts/llvm-dependencies.yaml
and I see it enabled there. (there is a specific list of disabled
projects in that same file)
I'd double check that it's doing "check-all" or similar in the actual
build. If you have a recent review (might have to be of a clang-tools
related source file) you can follow the links to buildkite from
phabricator and check the logs.
Click on the Diff <123456> link from "Harbormaster completed remote
builds in B<123456>: Diff <123456>.", then copy the buildkite URL and
go to that to see the full job.
e) I'm not in a position to answer.
Hopefully some of that helps.
Thank you for the in depth response, you forced me to look deeper at my own mess!
It turned out the test failures was due to a “.clang-format” file which it didn’t understand C++ (i.e. it didn’t have a C++ entry, only a C# and Json entry, stuff I work on)
because I’m building my build/tests out-of-tree, the tests are looking up the tree for a .clang-format file and found it at a higher level, which happened to be a couple of levels up from the “build” directory i was using
I’d failed to notice the following error among all the failures
Configuration file(s) do(es) not support C++: C:\projects.clang-format
I half wonder if there should have been a default .clang-format/.clang-tidy file somewhere in the tree or be preconfigured to use LLVM style, so that it doesn’t search up and pick an out of tree .clang-format file.
This is the kind of thing that could easily confuse people just starting out, well it caught me out anyway!
Many thanks for your excellent help.
MyDeveloperDay
There are defaults at the root of the llvm repo:
https://github.com/llvm/llvm-project/blob/main/.clang-format
https://github.com/llvm/llvm-project/blob/main/.clang-tidy
Assuming you have those files too, perhaps the search logic isn't what
you expect. It could be going from the binary being tested rather than
the source tree.
You might be able to improve the testing by making sure that tests
that don't provide a custom .clang-format file don't end up escaping
the build folder. Seems like a test isolation issue.