This is an archive of the discontinued LLVM Phabricator instance.

[libTooling] Introduce general combinator for fixed-value `MatchConsumer`s.
AbandonedPublic

Authored by ymandel on Oct 18 2019, 10:39 AM.

Details

Reviewers
gribozavr
Summary

This revision generalizes the (deprecated) clang::tooling::text combinator to
a value combinator, which works for any type. Aside from being more general,
it resolves the naming confict between clang::tooling::text and
clang::transformer::text, which has a subtly different meaning.

Event Timeline

ymandel created this revision.Oct 18 2019, 10:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 18 2019, 10:39 AM

What are the use cases for non-text values?

I like the name text much better... If the name conflict is the issue, I think you could rename it to toText -- it would even read more fluently change(toText("abc")), also making it obvious that we are not changing *the text abc*, but we are changing the code to say "abc".

What are the use cases for non-text values?

I like the name text much better... If the name conflict is the issue, I think you could rename it to toText -- it would even read more fluently change(toText("abc")), also making it obvious that we are not changing *the text abc*, but we are changing the code to say "abc".

Another example use is: https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/RangeSelector.h#L29-L32, although I must admit that I hadn't thought of that before this patch. It's just the natural generalization (it's actually the K combinator form SKI fame). So, I haven't thought about other examples -- the primary motivation was just the naming.

That said, I'm not sure about toText because I consider the "to" as implicit in change. In fact, it might be a good idea to rename change to changeTo (WDYT?). What about any of asText, textMsg, textMessage? (I realize the unfortunate pun in the last two, but not sure that's worth caring about).

What are the use cases for non-text values?

I like the name text much better... If the name conflict is the issue, I think you could rename it to toText -- it would even read more fluently change(toText("abc")), also making it obvious that we are not changing *the text abc*, but we are changing the code to say "abc".

Another example use is: https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/RangeSelector.h#L29-L32, although I must admit that I hadn't thought of that before this patch. It's just the natural generalization (it's actually the K combinator form SKI fame). So, I haven't thought about other examples -- the primary motivation was just the naming.

That said, I'm not sure about toText because I consider the "to" as implicit in change. In fact, it might be a good idea to rename change to changeTo (WDYT?). What about any of asText, textMsg, textMessage? (I realize the unfortunate pun in the last two, but not sure that's worth caring about).

An alternative, is not to introduce a new combinator at all, and just use Stencils:

change(cat("abc"))

Or, add operator() to StencilPart and use those directly:

change(text("abc"))

Given that Stencil and Transformer are bundled in the same library, is there any strong reason for a client to avoid a dependency on Stencil?

In fact, it might be a good idea to rename change to changeTo (WDYT?).

I like it. It should combine well with all stencils, not just text.

An alternative, is not to introduce a new combinator at all, and just use Stencils:

I think we are converging on that in another review. Do you plan to pursue this patch still?

In fact, it might be a good idea to rename change to changeTo (WDYT?).

I like it. It should combine well with all stencils, not just text.

Agreed. Will do.

An alternative, is not to introduce a new combinator at all, and just use Stencils:

I think we are converging on that in another review. Do you plan to pursue this patch still?

Agreed. Let's drop this one.

ymandel abandoned this revision.Nov 1 2019, 11:37 AM