This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Make parser revert digraph "<:"
Zack Weinberg wrote:
>> Rather, it is intented that in this specific case, '<::' be lexed
>> as < ::. That is different from throwing random pragmas in.
> Okay, but are there not other such problems, or are <:: and >> the
> only trouble spots?
I can't think of any other major lexing problem.
>(I wonder if anyone will request a do-what-I-mean mode, in which this
>and other places where template syntax clashes with greedy tokenization
>are all parsed the way the programmer 'obviously' meant?)
My personal opinion is that both ">>" and "<::" could simply generate warnings
instead of hard errors. I didn't submit the patches in that way because it's
not the way GCC is currently behaving so I didn't want to break orthogonality.
Daniel Jacobowitz wrote:
>Will we get the error for a literal "A[:0>" also? I understand that
>that's not a meaningful construction, but the error message is still
>going to look really odd.
For the whole discussion, it must be noted that the patch takes effect only if
"A" is the name of a template and the rest of template argument list can then
be succesfully parsed. For instance, for this:
we get "expected primary-expression before ':' token", with or without my
patch. For this:
template <int> class A;
A [ : 0 : > k;
we get again the "expected primary-expression". And also for this:
template <int> class A;
A [:0> k;
we get the "expected primary-expression", because the substitution "A<::0>" is
not a valid C++ program. You need something *exactly* like this:
template <class> class A;
for the alternative error message to trigger. I could bet that this will never
happen. And not that we're losing a meaningful error message, since we
basically replace "syntax error". The substitution is *strictly*
context-sensitive, also because "[:" is a valid sequence in a C++ program in
other contexts (see my testcase for an example of this).
I would also notice that, when I submitted the patch to support ">>" instead of
"> >", nobody was worried that the substitution could be triggered in an
invalid contexts, changing the default "syntax error" message. And I think that
the ">>" substitution is much more likely to happen at the wrong spots than the
"[:" substitution is (and we're speaking basically of code with a random serie
of tokens, whose outcome would be "syntax error").
If people think it's *really* necessary, I can try propagating the DIGRAPH flag
from cpplib up to the C++ parser. It looks to me that the less intrusive change
would be modifying c_lex so that it stores this information in the value tree
for the token (maybe making it a integer_zero_node, instead of null_tree, when
the token came from a digraph?). But I really think this is not worth it.