[PATCH 00/89] Compile-time gimple-checking

[Andrew MacLeod]

On 04/22/2014 01:50 PM, David Malcolm wrote:
> On Tue, 2014-04-22 at 09:05 -0400, Andrew MacLeod wrote:
>
>> Of course, it would be ideal if we could use 'gimple' as the namespace,
>> but that is currently taken by the gimple statement type... I'd even go
>> so far as to propose that 'gimple' should  be renamed 'gimple::stmt'..
>> but that is much more work :-)
> I'm not at all keen on that further suggestion: I wanted to make this
> patch series as minimal as possible whilst giving us the compile-time
> tracking of gimple codes.  Although people's inboxes may find this
> surprising, I was trying to be conservative with the patch series :) [1]
I wasn't suggesting you do it in this patch set... It would clearly be 
its own patch set, and doesn't even need to be done by you. Merely 
bringing up the option for future consideration since I'd like to see 
the generic 'gimple' name re-purposed :-)


>
> We're both working on large changes that improve the type-safety of the
> middle-end: this patch series affects statements, whereas AIUI you have
> a branch working on expressions and types.   How do we best co-ordinate
> this so that we don't bitrot each other's work, so that the result is
> reviewable, and the changes are understandable in, say, 5 years time?
> My plan was to do the statement work as a (large) series of small
> patches against trunk, trying to minimize the number of lines I touch,
> mostly function and variable decls with a few lines adding is_a and
> dyn_cast, whereas your change AIUI by necessity involves more
> substantial changes to function bodies.  I think we can only have zero
> or one such "touch every line" change(s) landing at once.
>
> Dave

I don't think you should worry about bit-rotting other in-progress 
branches when making these decisions...at least  not mine..  I think you 
should "do the right thing", whatever that turns out to be :-)

My stuff wont land as a "touch every line" change through the source 
base.  its designed to fully convert a file at a time and transparently 
coexist with the existing tree interface...  Impact on other files is 
minimal.  Plus I expect it will go through at least one more massive 
round of changes after I finish documenting it and bring it forth for 
discussions in the coming month(s).  So it'll be all bit-rotted then 
anyway.

Andrew