[cfe-dev] Proposal: add "replace" functionality to clang-query

[Yitzhak Mandelbaum via cfe-dev]

Agreed on all points.  Indeed, we have built a lightweight syntax for
ourselves but have not had the opportunity to upstream it yet. If you're
interested, I'd be happy to work with you on that.

On Wed, Mar 25, 2020 at 1:47 PM Alexander Timin <altimin at chromium.org>
wrote:

> Thanks Yitzhak and Aaron!
>
> As an outsider to the clang land, I wasn't aware of the Transformer —
> thanks for pointing me to it, it looks really exciting.
>
> I think that my proposal can be broken down into two parts:
> a) Adding an option to generate replacements without having to build a C++
> tool.
> b) Particular syntax to generate these replacements.
>
> I think that Transformer effort covers only the b) part — please correct
> me if I'm wrong.
>
> And out of these two, I (looking at the things from the user perspective)
> think that a) is the most important one, as having to write
> and link C++ code adds a lot of friction to the process (so sed + manual
> edits are still faster). So I think that there is a nice synergy
> potential in the long term — I think that the ideal end state would be
> having the ability to write Transformer-based queries dynamically in
> clang-query, something like that:
>
> $ clang-query
> > transform matcher makeStencil(ifBound("value", true, false))
>
> However (as building the dynamic Stencils sounds non-trivial), I think
> that there is no particular harm in having both options available in
> clang-query, one being easier to write and one being more flexible:
>
> > replace matcher foo = ${foo}
> > transform matcher complexStencil(...)
>
>
> On Wed, 25 Mar 2020 at 17:05, Yitzhak Mandelbaum <yitzhakm at google.com>
> wrote:
>
>> Aaron, thanks for mentioning Clang Transformer. Alexander, you can find
>> the original doc here
>> <https://docs.google.com/document/d/1ppw0RhjwsrbBcHYhI85pe6ISDbA6r5d00ot3N8cQWeQ/edit#heading=h.qjjywl5dhpsb>.
>> The code is under Tooling:
>> https://github.com/llvm/llvm-project/tree/master/clang/include/clang/Tooling/Transformer
>>
>> On Wed, Mar 25, 2020 at 12:52 PM Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>
>>> On Tue, Mar 24, 2020 at 4:22 PM Alexander Timin via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>> >
>>> > Hey!
>>> >
>>> > I think that medium-scale medium-complexity C++ refactorings (like
>>> replacing the order of the two arguments of a function across a large
>>> codebase) are much harder that they should be: clang-refactor and
>>> clang-rename do not cover them and writing a full libTooling tool is not
>>> the most time-efficient solution.
>>> >
>>> > I propose extending the functionality of clang-query to cover this use
>>> case and allow generating replacements (which can be then applied by
>>> clang-apply-replacements) from matches:
>>> >
>>> > replace MATCHER NODE PATTERN
>>> >
>>> > for example,
>>> >
>>> > let f = cxxMethodDecl(hasName("Foo"))
>>> > let arg1 = hasArgument(0, expr().bind("arg1"))
>>> > let arg2 = hasArgument(1, expr().bind("arg2"))
>>> > let m = callExpr(on(f), arg1, arg2)
>>> > replace m root Foo(${arg2}, ${arg1})
>>> >
>>> > A more detailed design doc is available here.
>>> >
>>> > An early prototype patch is available here.
>>> > A real-life example: the query is here, the output in the form of a
>>> Chromium patch is here.
>>> >
>>> > WDYT?
>>>
>>> Thank you for bringing up this idea, I've wanted something that can do
>>> this for a while. I think the idea has a lot of merit, but I'm
>>> wondering whether we want to focus on code transformations within
>>> clang-query like this as opposed to putting that effort into the
>>> in-progress Transformer work
>>> (http://lists.llvm.org/pipermail/cfe-dev/2019-January/060950.html).
>>> Are you aware of those efforts? If so, how do you see this proposal
>>> coexisting with that functionality?
>>>
>>> ~Aaron
>>>
>>>
>>> > Alexander
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200325/eaf62c2f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200325/eaf62c2f/attachment-0001.bin>