[cfe-dev] RFC: Easier AST Matching by Default

[Stephen Kelly via cfe-dev]

On 22/06/2020 07:52, Richard Smith wrote:
> On Sun, 21 Jun 2020 at 13:51, Stephen Kelly via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>
>     So, where to from here?
>
>     Does the default have to be changed back to AsIs? Does
>     IgnoreUnlessSpelledInSource have to be removed? Does the
>     traverse() matcher have to be removed?
>
> I would like to hear the opinions of others on these questions. I 
> think we've both described our perspectives and made our cases.
>
>
> Just expanding on my position from earlier in this thread slightly: to 
> directly address the "where to from here?" question, I would like us 
> to get back to the state where, /in our default mode, the matcher for 
> AST node X is always able to match all instances of AST node X/.


With the change I made to the default mode yesterday, this is now the case.


> And I think it's fine (and probably good) to expose an easy way to 
> explicitly control whether we automatically look through implicit 
> nodes or not.


I'm interested in continuing this part.

However, Richard, there seems to be room for interpretation of what your 
position is. I have a proposal for where to go from here. Please 
indicate whether you support or object to it:

I know of bugs in IgnoreUnlessSpelledInSource and those bugs can be 
fixed. I have known about them since before changing the default, but I 
thought incorrectly that I would be able to fix them after changing the 
default.

For example template instantations and the compiler-supplied parts of 
range based for loops are not "spelled in source" and should be ignored 
in that mode.

https://godbolt.org/z/x9osE8
https://godbolt.org/z/RXGCCB

Your response here is being interpreted by other people to mean I should 
not fix those bugs.

Can you clarify?

My proposal is that I fix those and similar bugs in 
IgnoreUnlessSpelledInSource. That way the mode can prove itself.

Do you support or object to that or neither?

Thanks,

Stephen.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200704/5bdc6116/attachment.html>