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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
