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

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Thu, 7 Jun 2001, Elena Zannoni wrote:

> 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
>

This isn't relevant, since it won't work now anyway.

We never evaluate the expressions involved in decode_line_1. We just want
to get names.

Try "break (1 < 0):10 ? 5"

It won't breakpoint line 10 or 5, you'll get an error.
;)

This is because we don't ever use the expression evaluator on the
expressions involved.  Line specifications aren't part of the expression
syntax. If they were, we'd just be able to use the language parsers and be
done with it.

It would also mean "print <filename>:<function name>" would work.


> 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
>
~