[cfe-dev] How to implement equals(0) in clang-query

[Samuel Benzaquen via cfe-dev]

On Mon, Dec 26, 2016 at 3:45 PM, Mads Ravn <madsravn at gmail.com> wrote:

> Hi,
>
> I have been wondering how to implement 'equals' for integer literals in
> clang-query. It doesn't seem to be working for string literals either. In
> Registry.cpp it says: "TODO: Here is the list of the missing matchers,
> grouped by reason." - here 'equals' is listed under 'Other'.
>
> So I guess there is a reason why it is not working for clang-query. Does
> anyone know what this reason is?
>

I put it in the list.
It requires more work than seemed appropriate at the time.
The function is a template, which we don't support yet in the dynamic
matcher layer.
Also, it supports types that are not supported in the parser, like floats.


> I wouldn't mind fixing it, but the few things I have tried have all
> resulted in failures. I am not sure why it works in clang-tidy, but not in
> clang-query. Aren't they using the same code-base for matchers? I can see
> equals implemented in ASTMatchers.h, but why can't clang-query use that?
>
> Can anyone point me in the right direction as how to implement this in
> clang-query? I imagine there is some blocking issue since it is not
> implemented already.
>

I think the "easiest" way is to make a custom dynamic matcher.
But we tried very hard not to make these.
Instead, we made the original matchers compatible to make sure we are
running the same code in both.

There are a couple ways to make this work:
 1) Remove the template on equals() and list all the overloads we want
manually.
 2) Make equals a functor, add a type list of "accepted types" and add a
special marshaller for that pattern.

(2) is a lot of work, but would be a generic solution.
This is how polymorphic matchers work.
However, I think for this case (1) is best. I don't know if we would reuse
the generality of (2).

Another option similar to (1) is to add the specific overloads we want in
clang-query and leave the template to handle everything else.


> Best regards,
> Mads Ravn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170109/b9e950c0/attachment.html>