Part 1 of Zack's integer parsing overhaul

[Zack Weinberg]

On Wed, May 29, 2002 at 06:06:40PM +0100, Neil Booth wrote:

> > CPP_N_ZERO was wanted by the new C++ parser.
...
> Yes; my idea is that the relevant code in the front end has the token
> so it can just do
> 
>   if (value.low == 0 && token->val.str.len == 1)

Works for me.

> > > +	    SYNTAX_ERROR ("excess decimal point in number");
> > 
> > This reads as ungrammatical to me.  I would say "too many decimal
> > points in number".
> 
> Done.  What I *really* want is caret diagnostics.  If we have that,
> I think we can justifiably simplify many "overly precise" diagnostics
> like this to be just "syntax error in numeric constant" or somesuch,
> and by pointing to the precise character that raised the problem
> it is at least as obvious what the problem is.

I think it's worthwhile being detailed about what's wrong even if we
do have caret diagnostics.  More detail means less chance for
confusion.

> I would work on implementing this tomorrow.  The only thing preventing
> me doing so is agreeing a format for diagnostics, so it's obvious to
> a tool where one ends and the next begins.  It is pointless attempting
> it if we can't filter the caret and the quoted line within DejaGnu,
> or at least extract the real diagnostic message from the surrounding
> bumph.

G77 has caret diagnostics already - you might see if that style will
do.  I don't have any better ideas at the moment, anyway.

We need to keep printing line numbers.  Column numbers are less
useful, though an editor might still want to know.  (Though an editor
might be better served by absolute byte offsets in the file.)

> >   "standard %s does not include imaginary numeric constants",
> >   language_name[CPP_OPTION (pfile, lang)]
> > 
> > where language_name contains appropriate strings.
> 
> The problem with that is what to print for the gnu "standards" and
> assembler.  I've avoided the issue by instead writing
> 
>     "imaginary constants are a GCC extension");

Sounds good to me.

zw