[PATCH] D54141: [clang-tidy] add deduplication support for run-clang-tidy.py

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

> Maybe my suggestion was not clear. The yaml file generated by clang-tidy contains not only replacements, but all diagnostics, even without a fixit.
> 
> So, running `clang-apply-replacements --issue-diags the_new_file.yaml` would issue the warnings/fixit hints by processing the yaml and issuing the diagnostics the way clang-tidy would have done (See in my proposed design that we silence clang-tidy).
> 
> Note also that the `--issue-diags` option does not yet exist. I'm proposing adding it.

At the moment `clang-apply-replacements` is called at the end of an clang-tidy run in `run-clang-tidy.py` That means we produce ~GBs of Yaml first, to then emit ~10MBs worth of it.
I think just relying on `clang-apply-replacements` is not ok.
If we do a hybrid: on-the-fly deduplication within `clang-tidy`/`run-clang-tidy.py` and a potential final deduplication with `clang-apply-replacments` we get the best of both worlds. 
That fits the distributed use-case as well(? I don't use a distributed system for these things as my projects are too small), because the first stage is local, the second stage central after all local workers are done.

> It seems that the bulk of the testing part of this commit is parsing a real-world log that you made. I guess if you remove the parsing (by taking a machine-readable approach) that bulk will disappear anyway.

That is true. The lat bit you have to convince me is on-the-flight output to see whats going on. I personally usually just take the raw textual representation and grep/scroll through it to see whats going on. It might be a bit of a tension between large-scale and small/medium scale applications.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D54141