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

[Daniel Berlin <dan at cgsoftware dot com>]

Jim Blandy <jimb@zwingli.cygnus.com> 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;

Only if x and y were constant, of course.

Though i don't believe the ternary operator is allowed there, gcc
certainly doesn't like it.

You could change the example to struct list < (x < y) > l; and get the
same effect, however. I tried it just for kicks.

You'd have to be pretty f*cked up to write that though.
Especially at debug time. I could see a macro doing it, however.



> 
> So how does our poor little decode_line_1 handle that?  Basically, we
> need to replace decode_line_1 with a real parser.
> 
> 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.
Yes, I knew this would cause problems with constant expressions,
however the solution to that without a real parser, is, of course, not
possible.

Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
expression parser if anyone is interested in the work.  I'll
eventually submit it once the hooks to do the necessary gdb lookups to
handle macros are done.  Neil said he'd try to have something

I also submitted patches to gcc to make it produce the dwarf2 macro
info necessary for us to let the user use macros from GDB that are
used in the source.

So this problem is only going to get worse.

If i wasn't in the middle of redoing the type system, and having it go
so well so far, i'd  probably work more on replacing the decode_line_1
parser.


-- 
"Under my bed I have shoe box full of telephone rings.  Whenever
I get lonely I open it up just a bit and I get a call.  One time
I dropped the box all over the floor and the phone wouldn't stop
ringing, so I had it disconnected.  I bought a new phone though.
I didn't have much money so I had to buy an irregular phone --
it had no number 5 on it.  I saw a close friend of mine the
other day...  He said, "Steven, why haven't you called me?"  I
said, "I can't call everyone I want.  My new phone has no five
on it."  He said, "How long have you had it?"  I said, "I don't
know...  My calendar has no sevens on it."
"-Steven Wright