This patch has 2 rationales:
- large patches lead to long command lines and often cause max command line length restrictions imposed by OS;
- clang-tidy runs are independent and can be done in parallel, the same as done for run-clang-tidy.
Differential D57662
[clang-tidy] Parallelize clang-tidy-diff.py zinovy.nis on Feb 3 2019, 11:29 AM. Authored by
Details
This patch has 2 rationales:
Diff Detail Event TimelineComment Actions Just a question.. If clang tidy is running with -fix in parallel, what stops each clang-tidy invocation altering a common header at the same time? Comment Actions
I only say this because I think I might have seen it happen when I was running run-clang-tidy.py over a large code base with a fairly aggressive check/fixit, but frankly I was too new to LLVM to know it wasn't something I might have done wrong. I saw my '[[nodiscard]]' checker splicing multiple [[nodiscard]]s onto the same line, I suspect there is a time of check/time of use issue for the locations, sometimes the positions where wrong by the time the Fixit came around. I guess because i'd used that script without specifiy a -j1 it just used the default which is -j0 which I guess goes as parallel as it can. Its only when you raised this review for the diff check that I wondered if that could be the cause. Comment Actions
A bit strange as run-clang-tidy.py explicitly collects fixes in separate files and after all merges them into a single fix in a thread/process-safe manner. Not like my current patch. Comment Actions clang-apply-replacements does it. The fixes are collected and then deduplicated and applied. If there are conflicts between the fixes at this stage they will be signaled.
Comment Actions A few more comments.
Comment Actions
Comment Actions LG with a nit
Comment Actions @zinovy.nis @alexfh @JonasToth @MyDeveloperDay Hi folks, please correct me if I'm wrong but it appears that an effect of this change is that this script will no longer exit non-zero if clang-tidy discovers any errors, which was the previous functionality with sys.exit(subprocess.call(' '.join(command), shell=True)). As a result, when we upgraded a project to LLVM 9 our CI began having false-positives, as we relied on the exit code of this script to indicate success/failure. Would it be possible to restore that functionality? I'd be happy to provide a patch. Comment Actions Yeah, that would be good to restore. run-clang-tidy.py is parallelized and does fail properly (95% sure about that xD), so in doubt you can check that script as well. |
if timeout is not None is more readable.