Re: [RFA] linespec.c change to stop "malformed template specification" error

[Elena Zannoni <ezannoni@cygnus.com>]

Jim Blandy writes:
 > 
 > Elena Zannoni <ezannoni@cygnus.com> writes:
 > > Daniel Berlin writes:
 > >  > This error is cause by find_toplevel_char not knowing that '<' and '>'
 > >  > increase and decrease the depth we are at.
 > >  > 
 > >  > The result is that if you say "break _Rb_tree<int, int>", when it goes
 > >  > to look for a comma at the top level, it thinks it found one right
 > >  > after the "int", and temporarily truncates the string to '_Rb_tree<int,'
 > >  > When we then proceed to go through the string, we see the "<", and
 > >  > then go to find the end of the template name, and can't, because we've
 > >  > truncated the string in the wrong place, and issue an error.
 > >  > 
 > >  > Cute, no?
 > >  > 
 > >  > --Dan
 > >  > 
 > > 
 > > Seems OK to me, but could you update the comment on top of the
 > > find_toplevel_char() to reflect that the char is looked for also
 > > outside of '<' and '>' pairs?
 > > 
 > > Any of the other maintainers (Jim, Fernando) has any comments?
 > 
 > Operators like '<' can appear in template arguments.  For example, you
 > could define a template like this:
 > 
 >         template <int i> struct list { int a[i], b[i]; };
 > 
 > and then use it like this:
 > 
 >         struct list <20> l;
 > 
 > and you get the same thing as if you'd written:
 > 
 >         struct { int a[20], b[20]; } l;
 > 
 > At least I think so, anyway.  I don't really know C++.  But the point
 > is, those template arguments can be any arbitrary constant expression.
 > So I could have a template invocation like this:
 > 
 >         struct list < (x < y) ? 10 : 20 > l;
 > 
 > So how does our poor little decode_line_1 handle that?  Basically, we
 > need to replace decode_line_1 with a real parser.

I am not sure that decode_line_1 will ever be invoked in such a case.
Looking at when it's called, it seems to be only when you specify 
a location, not an expression, and that occurs for 'break blah' and 
'list blah' only. Also, find_toplevel_char is called only when looking
for a comma, so even with your example it should still work fine,
even though the 'depth' variable will have an inaccurate value.

But yes, I agree, decode_line_1 is a mess.

Elena

 > 
 > In the mean time, however, I think it's more important to recognize
 > the template argument brackets at all than to handle template
 > arguments that contain < and > operators.
 > 
 > So with this caveat, I think the change is fine.
 >