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

[Stephen Kelly via cfe-dev]

On Wed 27 May 2020, 10:46 Stephan Bergmann, <sbergman at redhat.com> wrote:

> On 27/05/2020 11:34, Stephen Kelly via cfe-dev wrote:
> > On Wed 27 May 2020, 09:25 Sam McCall, <sammccall at google.com
> > <mailto:sammccall at google.com>> wrote:
> >     In summary: it requires changes in consuming tools that are
> >     numerous, hard to find, hard to analyze, must all be done at once,
> >     and the changes aren't mechanically reliable.
> >
> >
> > Hmm, the location to call setTraversalKind on the ParentMapContext in
> > each external tool should be easy to find? Should be easy to analyze
> > too. There is presumably fewer places in your tool (or just one place in
> > the entire tool)  where ASTContexts are created, so "all" is either "1"
> > or close to it?
> >
> >     I expect this to bite people building tools against release versions
> >     to hit the same problems in a few months.
> >
> >
> > Perhaps the solution of changing the setting in the ParentMapContext
> > needs to be spelled out better in the release notes. It would also be
> > good to know whether doing so makes the impact on your tools manageable.
> > Can you look into that?
>
> As a side note:  When adapting LibreOffice's Clang plugin to this
> change, it wasn't clear to me whether that plugin would be allowed to
> call setTraversalKind (to set it back to the old TK_AsIs) on the global
> CompilerInstance's ASTContext's ParentMapContext, so I ended up using a
> private ParentMapContext for the plugin
> (<
> https://git.libreoffice.org/core/+/09aa5a9be8b9b3c88cf25b85e0eda28c5ef19aa4%5E!/>
>
> "Adapt to changed clang::ASTContext::getParents behavior on Clang 11
> trunk").



Thanks for the feedback. I can at least update the release notes to make
this more clear.

Thanks,

Stephen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200527/90772f07/attachment-0001.html>