Re: Adjust locations for RECORD_TYPEs

[Taras Glek <tglek at mozilla dot com>]

On 11/25/2009 04:03 PM, Gabriel Dos Reis wrote:
> On Wed, Nov 25, 2009 at 5:41 PM, Taras Glek<tglek@mozilla.com>  wrote:
>    
> > On 11/25/2009 03:36 PM, Gabriel Dos Reis wrote:
> >      
> > > On Wed, Nov 25, 2009 at 5:02 PM, Taras Glek<tglek@mozilla.com>    wrote:
> > >
> > >        
> > > > On 11/25/2009 03:00 PM, Richard Guenther wrote:
> > > >
> > > >          
> > > > > On Wed, Nov 25, 2009 at 11:57 PM, Taras Glek<tglek@mozilla.com>
> > > > >   wrote:
> > > > >
> > > > >
> > > > >            
> > > > > > Hi,
> > > > > > Currently locations for structs point at {, which is frustrating in
> > > > > > error
> > > > > > messages and painful if one uses GCC to index their codebase (ie
> > > > > > http://australia.proximity.on.ca/dxr/)
> > > > > >
> > > > > > This patch attempts to correct that such that the location of a
> > > > > > RECORD_TYPE
> > > > > > will be the location of the class name.
> > > > > >
> > > > > >
> > > > > >              
> > > > > What will be the location for anonymous RECORD_TYPEs?
> > > > >
> > > > >
> > > > >            
> > > > End of struct/class token.
> > > >
> > > >          
> > > Well, that looks weird to me, compared to the existing behaviour.
> > >
> > >
> > >        
> > Existing behavior is problematic for
> > class foo
> > : public parent
> > {
> > }
> > programming style because any error messages/etc point to {, which often
> > means that { is on top of the screen when you jump to that location, making
> > one scroll up to get some context.
> >      
> '{' is where the type definition is, and it is where it works well for
> both named and unnamed user-defined type.
>    
I disagree, I think it is reasonable consider class name and inheritance 
info part of the definition.
> If your concern is for supporting a some coding standard, I think
> that is should be the job of external tools, and all GCC has to do
> is to emit enough location information -- so that anyone can
> guide their IDE to support the favorite coding standards.
>
> Consequently, I don't see this change as appropriate.
>    
My concern is the location does not show the class name and other 
relevant info. I'm not trying to support any particular coding standard, 
just showing that the current method is insufficient. Unfortunately due 
to the complexity of the language, parsing C++ is a job that external 
tools should leave to GCC, so if GCC does not provide sufficient 
location resolution, there is little that the tools can do.

See
http://australia.proximity.on.ca/dxr/search.cgi?tree=mozilla-central&amp;derived=nsISerializable
and follow the link to nsStandardURL. Note how the top of the class is 
scrolled off the screen. The same clipping of context happens in error 
messages.

I don't see how pointing at where the type definition actually begins is 
any worse than the current behavior.

Taras