[diagnostics-branch] use precise locations in C front-end

Aldy Hernandez aldyh@redhat.com
Wed Jan 21 17:54:00 GMT 2009


On Mon, Dec 15, 2008 at 12:04:56PM -0700, Tom Tromey wrote:
> >>>>> "Aldy" == Aldy Hernandez <aldyh@redhat.com> writes:
> 
> Aldy> The following patch is a top down approach for adding more precise
> Aldy> location information to the C front-end.  We start with the parser, and
> Aldy> push locations down as we build expressions and declarations.
> 
> I gave this a try over the weekend on a project I'm working on.

Sorry I took so long.  I was on vacation.

> First, you may want to flip the default to -fshow-column on the
> branch.  I think that will show the errors more nicely.

I plan to do a merge this week, and then try to turn on fshow-column and
fix the fall out from the testsuite.  Thanks.

> Second, -fshow-column as-is does not interact nicely with Emacs.
> According to the GNU standards, GNU programs should count columns
> starting at 1 and then:
> 
>     Calculate column numbers assuming that space and all ASCII
>     printing characters have equal width, and assuming tab stops every
>     8 columns.
> 
> We currently print logical column numbers, instead.  While I think
> this would be a better design, presumably other GNU programs already
> follow the above.
> 
> Emacs, despite the default setting of compilation-first-column, seems
> to actually be using zero-based columns.  If you change cpp_buf_column
> to be 1-based, you get the wrong results in Emacs :(
> 
> So, I came up with the appended.
> 
> I'm not checking this in yet.  Perhaps we should try to change the GNU
> standards first, or at least fix the Emacs bug.  Also, we probably
> should consider caching the most recent column in the buffer.
> 

Looks good.  Feel free to commit it.  I'll leave the emacs hacking to
you ;-).

Thanks.
Aldy



More information about the Gcc-patches mailing list