This is the refactoring to lift some FixItHint into tooling.
used by: http://reviews.llvm.org/D19807
Details
Diff Detail
Event Timeline
If this is what you wanted Alex, I'll pursue writing unittests/docs and making a complete patch to land.
See some example on how to use it:
http://reviews.llvm.org/D19807
Yes, this looks reasonable.
| include/clang/Tooling/Fixit.h | ||
|---|---|---|
| 2 | nit: Should be FixIt (note the capital I). | |
| 36 | Do we want to expose getSourceRange as an API? If no, it should also be in the namespace internal. | |
| 56 | I wonder whether we should later extend this to remove comments attached to nodes like Stmt and FunctionDecl? It's out of this patches scope, but maybe add a FIXME to sketch the further development plans. | |
| include/clang/Tooling/Fixit.h | ||
|---|---|---|
| 1 | nit: s/FixIt Hint/FixItHint/, since this is a reference to the type. | |
| lib/Tooling/CMakeLists.txt | ||
| 10 | Please rename the files as well (s/Fixit/FixIt/). | |
| unittests/Tooling/CMakeLists.txt | ||
| 15 | s/FixitTest/FixItTest/ | |
| unittests/Tooling/FixitTest.cpp | ||
| 34 | Automatic captures always seem suspicious to me. What exactly does this lambda need to capture? If just this, I'd rather make the capture list explicit. | |
| 53 | Could you add a test where getText returns an empty string? | |
| 119 | One character range is boring. Can you make the parameter longer and also verify whether the range is a token range or a character range? | |
LG. Thanks!
| unittests/Tooling/FixItTest.cpp | ||
|---|---|---|
| 37 ↗ | (On Diff #56826) | Let's either put the tests in the clang::tooling::<anonymous> namespace (not common for unit tests in this specific directory, but nevertheless reasonable, imo) or add using declarations for tooling::fixit::getText and other tested functions to reduce the amount of boilerplate. |
I added the "using statements".
landing.
| include/clang/Tooling/Fixit.h | ||
|---|---|---|
| 36 | Good question. If it's become needed, we can re-expose it. | |
| 56 | I like the idea. I didn't think about comments and other syntactical elements that may be related to a Node. An other concept that I believe it's missing is to provide helper to append expression (operators) and stay semantically correct with operator precedence. Some cases needed to add parentheses. | |
| unittests/Tooling/FixitTest.cpp | ||
| 53 | see line 68, already there! | |
| 119 | In this case, it's not one character... it's one token. But, I can use an expression too. There is already a reand at line 138: EXPECT_EQ("input.cc:2:26 <Spelling=input.cc:1:37>",
EXPECT_EQ("input.cc:2:26 <Spelling=input.cc:1:45>", | |
nit: s/FixIt Hint/FixItHint/, since this is a reference to the type.