This is an archive of the discontinued LLVM Phabricator instance.

[libTooling] Add `run` combinator to Stencils.
ClosedPublic

Authored by ymandel on Sep 24 2019, 9:28 AM.

Details

Summary

This revision adds run, a StencilPart that runs a user-defined function that
computes a result over MatchFinder::MatchResult.

Diff Detail

Repository
rL LLVM

Event Timeline

ymandel created this revision.Sep 24 2019, 9:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 24 2019, 9:28 AM
ymandel updated this revision to Diff 221554.Sep 24 2019, 9:31 AM

clang-format

gribozavr added inline comments.Sep 25 2019, 5:47 AM
clang/include/clang/Tooling/Refactoring/Stencil.h
181 ↗(On Diff #221554)

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 ↗(On Diff #221554)

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.

ymandel marked an inline comment as done.Sep 25 2019, 5:58 AM
ymandel added inline comments.
clang/include/clang/Tooling/Refactoring/Stencil.h
181 ↗(On Diff #221554)

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.

gribozavr accepted this revision.Sep 25 2019, 7:42 AM
gribozavr added inline comments.
clang/include/clang/Tooling/Refactoring/Stencil.h
181 ↗(On Diff #221554)

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.

This revision is now accepted and ready to land.Sep 25 2019, 7:42 AM
ymandel marked 4 inline comments as done.Sep 25 2019, 12:33 PM

Thanks for the review!

clang/include/clang/Tooling/Refactoring/Stencil.h
181 ↗(On Diff #221554)

Yes, I like that! Pretty printing has obvious other benefits, which equality doesn't. Will do in followup patch. Thanks!

This revision was automatically updated to reflect the committed changes.
ymandel marked an inline comment as done.
Herald added a project: Restricted Project. · View Herald TranscriptSep 25 2019, 5:55 PM