On 09/21/2010 06:47 PM, Rodrigo Rivas wrote:
I'm holding out for rolling back the lexer in some way that won't break
everything and emitting the (unrecognized by cpp ) suffix as a separate
identifier token. I'm thinking the cp_lexer_* routines or maybe a new one in
parser.c would be worth trying. Then the code I have now would just work
(except I would still need enhanced lookup rules as discussed earlier). It
would be nice to have all types on the same page too.
Hmmm, you indend to break the user-defined integer/float into two
tokens: the number and the suffix. I don't know... it may cause quite
some unexpected problems. Note that the draft defines a
user-defined-literal as *one* token but you want to read it as *two*
tokens.
That would make ill-formed code parseable, for example:
int x = 10 /* whatever */ _foo;
On second thought, this already happens with strings and chars:
"xxx" /**/ _bar;
is parsed fine with your current patch, but I believe it should not.
Rodrigo.
I'm coming around to your idea. I'm giving up on tokenizing tricks.
We got "lucky" with chars and strings because there was no pre-existing
significance to a suffix in those cases.
I haven't tried it but I think this would "pass":
"Hello, World!" _foo;
with space between the string and the suffix.
I know this passes but shouldn't:
operator ""E(long double);
with no space between the string and the 'E'.
Maybe once I get numbers working I'll turn to those issues.
Ed
