[clang-tidy] Run `run-clang-tidy` and `clang-tidy-diff` scripts in parallel implicitly

[vbvictor]

When the user does not specify -j flag in run-clang-tidy or clang-tidy-diff it would be better to run everything in parallel by default.
From my experience, other linters try to run in parallel by default, for example cargo clippy, golangci-lint, revive.

I think we should add implicit call to multiprocessing.cpu_count() in run-clang-tidy and clang-tidy-diff and use that number if user didn't specify -j explicitly.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Baranov Victor (vbvictor)

When the user does not specify `-j` flag in `run-clang-tidy` or `clang-tidy-diff` it would be better to run in parallel. From my experience, other linters try to run in parallel by default, for example `cargo clippy`, `golangci-lint`, `revive`.

I think we should add implicit call to multiprocessing.cpu_count() in run-clang-tidy and clang-tidy-diff and use that number if user didn't specify -j explicitly.

[EugeneZelenko]

But does multiprocessing.cpu_count() recognize managed environment like LSF? Tasks that abuse resources may be killed.

[vbvictor]

But does multiprocessing.cpu_count() recognize managed environment like LSF? Tasks that abuse resources may be killed.

Hm, It would not. However, if user run clang-tidy in CI, he can explicitly put the number of threads via -j. When developer use run-clang-tidy locally, I don't see many drawbacks of using $nproc. But this is only my opinion based on other linters/build_systems like golangci-lint, go build, cargo build which run on all available threads by default.

With run-clang-tidy we can provide a log message that will say Running in X treads in parallel.