This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
--------------
A[:0> k;
--------------
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;
class B;
A[:B> k;
--------------
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.

Giovanni Bajo



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]