This revision adds run, a StencilPart that runs a user-defined function that
computes a result over MatchFinder::MatchResult.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38491 Build 38490: arc lint + arc unit
Event Timeline
clang/include/clang/Tooling/Refactoring/Stencil.h | ||
---|---|---|
181 | We could reimplement all other stencils through run() and eliminate StencilPartInterface. The idea is to make StencilPart contain a std::shared_ptr<MatchConsumer<std::string>>. Then run() can be implemented as creating a StencilPart directly, and everything else can be implemented in terms of run(). WDYT? | |
clang/lib/Tooling/Refactoring/Stencil.cpp | ||
107 | Not very appropriate for this review -- but why do Stencils support equality comparison? As you note, with things like run it makes little sense to support it as an API. However, since a user does not know whether a Stencil can contain run or not, it is not very meaningful to compare them at all. So if equality is not used for anything important, consider removing it? Not to even mention that as implemented, equality is not reflexive. |
clang/include/clang/Tooling/Refactoring/Stencil.h | ||
---|---|---|
181 | Answering both questions together: the equality function is designed to make testing of the format-string parser feasible (or, at least, reasonable). As is, the only reason not to do what you suggest above is exactly the equality function -- otherwise, StencilPart is just std::shared_ptr<MatchConsumer<std::string>>. I can also plausibly imagine that we'll extend the interface to include a "print" function as well at some point. However, currently the parser hasn't been upstreamed and the print function is only an idea, so it would be reasonable to drop StencilPartInterface and all the associated baggage and we could reinstate it later as needed. Or, if you can think of a good way to test the parser that doesn't require an equality function, that too would be convincing. |
clang/include/clang/Tooling/Refactoring/Stencil.h | ||
---|---|---|
181 | Ilya suggested that rather than comparing objects, a better way is to compare pretty-printed strings. First, it avoids the need for equality (which might get used for other things), and second, test failures will be more debuggable because we will have an obvious diff in the pretty printed string. With that, I agree that StencilPartInterface has to stay since we are going to have at least two operations. |
Thanks for the review!
clang/include/clang/Tooling/Refactoring/Stencil.h | ||
---|---|---|
181 | Yes, I like that! Pretty printing has obvious other benefits, which equality doesn't. Will do in followup patch. Thanks! |
We could reimplement all other stencils through run() and eliminate StencilPartInterface.
The idea is to make StencilPart contain a std::shared_ptr<MatchConsumer<std::string>>. Then run() can be implemented as creating a StencilPart directly, and everything else can be implemented in terms of run().
WDYT?