Autoformatting seems like a good idea to me. I don't have any particular preference between the LLVM style and the Google style. The GNU style looks pretty weird to me and is very different to the way our Rust code is styled, so I'd prefer not that.

We should probably enforce the style, either via a CI check like we currently have for our Rust code, or plausibly via a test, which has the advantage that it's harder for a new contributor to miss.

I don't have any particular preference between the LLVM style and the Google style. The GNU style looks pretty weird to me and is very different to the way our Rust code is styled, so I'd prefer not that.

There are things that I prefer in Google style over LLVM and vice versa, so I have no strong opinion on these two. I don't like GNU style, but it's a huge OSS community, therefore I included it.

or plausibly via a test

Which we probably should call tidy, like in Rust's repo.

I welcome the suggested change and I don't have any style preference ;)

Example from Tumbleweed job:

Looking deeper into it, I slightly prefer Google version, so went for it.
The way it works currently, it creates a new test for every file that we want to format with clang-format which obviously has some overhead (especially for nextest with spawns each test in a separate process):

# with hot cache
❯ time cargo t clang_format_check
...
________________________________________________________
Executed in  202.20 millis    fish           external
   usr time    1.15 secs      0.00 micros    1.15 secs
   sys time    1.66 secs    714.00 micros    1.66 secs


❯ time cargo nextest run clang_format_check
...
________________________________________________________
Executed in  345.40 millis    fish           external
   usr time    1.33 secs      0.00 micros    1.33 secs
   sys time    2.25 secs    836.00 micros    2.24 secs

Open questions:

• should we do it as a single test? With hot cache, this brings the time down to 100 milliseconds and 200 milliseconds respectively.
• do we want to run it by default or make it configurable
  • if so, which agents should run it?
• do we want some kind of env variable or something to automatically bless (format) these files?
  • alternatively, we could document how to configure popular editors

• should we do it as a single test? With hot cache, this brings the time down to 100 milliseconds and 200 milliseconds respectively.

Given the time difference, I'd be in favour of running it all in a single process - not just the rust test, but also a single invocation of clang-format. At least on my system, that makes quite a difference.

Running a separate clang-format for each file takes 0.94 seconds on my laptop.

time bash -c 'for i in *.c *.h *.cc; do clang-format --dry-run $i; done'

Running all in one process takes only 0.11 seconds.

time bash -c 'clang-format --dry-run *.c *.h *.cc'

• do we want to run it by default or make it configurable

I think just running it by default makes sense. If we didn't run it by default, but then did run it in CI, then sometimes people would send a PR and have it fail CI. Better if they know before they send their PR that there's stuff that needs fixing. Having a way to turn it off seems reasonable though. e.g. setting WILD_SKIP_FORMAT_TESTS=1 or something like that.

• do we want some kind of env variable or something to automatically bless (format) these files?

I'd be fine with that. The other option would be to have the test print out a command that you can run that would fix the formatting. e.g. something like clang-format wild/tests/*.{c,h,cc}

If you wanted to submit the formatting changes of the existing tests in this PR and do the formatting test in a separate PR, that would be fine by me.

Running a separate clang-format for each file takes 0.94 seconds on my laptop.

time bash -c 'for i in *.c *.h *.cc; do clang-format --dry-run $i; done'

Running all in one process takes only 0.11 seconds.

time bash -c 'clang-format --dry-run *.c *.h *.cc'

This is not fully representative of how this test works because you run all files serially. The test runs them with all CPU threads, so it's way faster, but obviously it will always be slower than a single invocation.

If you wanted to submit the formatting changes of the existing tests in this PR and do the formatting test in a separate PR, that would be fine by me.

That was my initial idea but went ahead and repurposed the PR, unless you think it'd be beneficial for the review to split it up.

This is not fully representative of how this test works because you run all files serially. The test runs them with all CPU threads, so it's way faster, but obviously it will always be slower than a single invocation.

That's true, however generally you'd be running the entire test suite, so even if we only use a single thread for checking formatting, it'll run in parallel with other tests. In any case, the speed of either approach probably uses sufficiently little CPU / time that it doesn't matter, so I'd say go with whatever approach is easiest.

That was my initial idea but went ahead and repurposed the PR, unless you think it'd be beneficial for the review to split it up.

That's fine. Whatever is easiest.

This is how it looks right now, obviously the second time tests were run they passed.