As opposed to the clang-fixit tool described on http://clang.llvm.org/docs/ClangTools.html, this adds -fixit option to clang-check. Thus, clang-check can become a general-purpose tool to run clang capitalizing on the info stored in a compilation database.
Details
Diff Detail
Event Timeline
General comment: why do we need a separate tool at all? Can't this simply be a "-fixit" option to the perhaps-to-be-renamed clang-check?
I had thought about that and could find any strong arguments for one or the other. Chandler: I think you have authored the webpage mentioning clang-fixit as a separate tool. Any reason why it should be a separate tool?
From the description on the page: "It is designed to explore alternative interfaces for applying fix-it hints, including automatic application, prompting users with options for different fixes, etc.", it seems like the tool is meant to be a bit more involved.
Bleh. Way too much boiler plate here. =/
tools/clang-check/ClangCheck.cpp | ||
---|---|---|
65–70 | By re-using the existing Clang options, you've made a bit of a surprising change here: The original 'clang-fixit' tool behaved as if passing both '-fixit' and '-fix-what-you-can' to Clang. The rationale was that because it is a separate explicit step, it is much less problematic to apply partial fixes. I think that logic continues to hold for a 'clang-check' variant. It seems a bit strange to require the extra flag here. =/ Oh well. Maybe in the docs somewhere, suggest creating a shell alias for 'clang-fixit' -> 'clang-check -fixit -fix-what-you-can' ? | |
93–103 | This class needs a comment about why the existing one won't suffice... | |
108 | Rather than a whole separate class above, why not just clobber the one option here? |
tools/clang-check/ClangCheck.cpp | ||
---|---|---|
65–70 | I agree that it is not ideal, but I would vote for being as consistent with the bare clang as possible. I will update the docs once this is submitted. | |
93–103 | Done. | |
107 | Done. | |
108 | Because all implementations (preferable we would reuse FixItRewriteInPlace) are defined in an unnamed namespace inside lib/Rewrite/Frontend/FrontendActions.cpp. Would you rather, I move those into clang/Rewrite/Frontend/FrontendActions.h? Also, we cannot just call clang::FixItAction::BeginSourceFileAction() as it installs clang::FixItRewriter() which we don't want. | |
140–141 | Done. |
LGTM
For what its worth, I think the amount of code we have added here clearly demonstrates why this should be a separate tool... but I'll leave that debate for another day. ;]
tools/clang-check/ClangCheck.cpp | ||
---|---|---|
108 | If we can effectively re-use an implementation, then yes, we should lift it into the public header file. It's not clear based on your last comment whether we can re-use it. I'm happy for this to be a follow-up patch though to clean things up. | |
110 | Probably should toss a comment on this class as well to keep a record of some of our discussion about why it is needed... |
Comment added and submitted as r165110. Cleanup CL as well as CL changing documentation will follow.
By re-using the existing Clang options, you've made a bit of a surprising change here:
The original 'clang-fixit' tool behaved as if passing both '-fixit' and '-fix-what-you-can' to Clang. The rationale was that because it is a separate explicit step, it is much less problematic to apply partial fixes.
I think that logic continues to hold for a 'clang-check' variant. It seems a bit strange to require the extra flag here. =/ Oh well.
Maybe in the docs somewhere, suggest creating a shell alias for 'clang-fixit' -> 'clang-check -fixit -fix-what-you-can' ?