[cfe-dev] Bugs 2746 and 3261

[Paolo Bolzoni]

On Wed, 14 Jan 2009 12:59:52 -0800
"Eli Friedman" <eli.friedman at gmail.com> wrote:
> On Wed, Jan 14, 2009 at 7:29 AM, Paolo Bolzoni <bolzoni at cs.unipr.it> wrote:
> > Let's see a simple but evocative example.
> > I have the clang AST of this code segment.
> >
> > Using the function that overrides
> > HandleTranslationUnit(clang::TranslationUnit&)
> > I want to pretty print:
> >
> > Here the code:
> > struct B;
> >
> > struct A {
> >  struct B* b;
> > };

> The approach I was thinking of is something like the following:
> suppose you're trying to pretty-print the "struct B* b;" bit.  Let S
> designate the location immediately before the keyword "struct", let E
> designate the location immediately after the semicolon, and let D
> designate the beginning of the definition of struct B.
But declaration have only one program point, I can't have both the position of
`struct' and of `;' in the line `struct B* b;'

It might work if I could have both...

Maybe FieldDecl and TypedefDecl should have isDefinition() like function too?
So we could distinguish easily if the type inside is defined there or not.


> Unfortunately, though, there isn't any easy way to compare source
> locations like that; it should be possible, I think, but I don't know
> the details of how to write it.  Also, I'm not sure if you can get the
> relevant source locations easily, particularly S.  I think ongoing
> work with DeclGroups will help here eventually, but I'm not sure of
> the details.
Since SourceLocation contains both line and column it would be easy to
implement an order. It is still a problem for tokens where isValid() or
isFileID()) are false, but maybe it is not possible in this context.


> There is another possible approach: take the location of the beginning
> of the first declarator in the declaration (the "*b" bit), and scan
> backwards through the source code to see if you find a "}" before the
> first occurrence of the "struct" keyword.  It's quite messy in terms
> of layering, and I'm not sure how preprocessor stuff would factor into
> it, but I think it's feasible.  I don't know the details here either,
> but I remember reading that the ObjC rewriter does some similar stuff.
This is indeed a problem to implement at AST level.
 
> I'm putting cfe-dev back onto the CC list so that people more familiar
> with this stuff can comment; this is really outside the stuff I've
> really tried.
> 
> -Eli
Thanks!
pb