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:
 > >  > 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.
 > 
 > Templates can expand to functions, too:
 > 

Ok, I was looking at your example in a myopic way.

 > template <int i>
 > int add_const (int j)
 > {
 >   return i + j;
 > }
 > 
 > then, add_const <4> (3) returns 7.
 > 
 > But add_const <4> and add_const <5> are different functions.  The
 > compiler emits separate code for each of them.  So you need to be able
 > to set a breakpoint on add_const <4>.  And the template argument to
 > add_const can be any constant expression.
 > 
 > So finding breakpoint names requires parsing (almost) arbitrary expressions.
 > 

Yes, you are correct. That function (find_toplevel_char) would get it wrong
if we had something like this, even with Dan's patch:

break foo_class<x>y ? 1 : 2, 4>::foo

It would think that the greater-than was the end of the template, and
that the ',' was outside of the template specification.  But, if that
is a legal expression (I am not sure), how likely would it be?
Definitely better with Dan's patch than w/o, at least we can catch the
simpler cases.

Elena