Re: [PATCH 03/17] Core of BLT implementation

[Jeff Law <law@redhat.com>]

On 07/24/2017 02:05 PM, David Malcolm wrote:
> This patch implements the core of the new "blt" type: an optional
> "on-the-side" hierarchical recording of source ranges, associated
> with grammar productions, with a sparse mapping to our regular
> "tree" type.
So I think one of the big questions here is whether or not BLT hits the
right compromise between the two syntax trees to meet the needs you
envision.  It's an area I'm not really versed in, so I'm probably not a
good judge of whether or not we're on the right track -- though it does
seem to my naive eyes that you need to have most of the tree to do
something like refactoring tools.

> 
> Caveats:
> * the name is a placeholder (see the comment in blt.h)
> * I'm ignoring memory management for now (e.g. how do these get freed?
>   possible a custom arena, or an obstack within a blt_context or
>   somesuch)
Yea, management is a real question.  It obviously depends on the use
case -- ie, are the use cases such that we expect to work on a function
level, then move on to the next function and so-on.  Or is it the case
that we are likely to need to build the BLT for function A, then analyze
some other code in function B, then go back and issue fixit hints for
function A?  ie, what are the expected lifetimes of a BLT.

My understanding is you can have nodes in the BLT pointing to trees and
vice-versa.  This may have implications on memory management :-)

Jeff