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

[Daniel Berlin <dan@cgsoftware.com>]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
>> Jim Blandy <jimb@zwingli.cygnus.com> writes:
>> > Daniel Berlin <dan@cgsoftware.com> writes:
>> >> > So finding breakpoint names requires parsing (almost) arbitrary
>> >> > expressions.
>> >> Only if you allow arbitrary names.
>> >> We don't.
>> >> So this leaves allowing a superset.
>> > 
>> > Sorry, I don't understand what you mean.
>> 
>> We don't allow expressions inside the line specifications right now.
>> 
>> Try "break (5 < 10) ? 10 : 20".
>> 
>> So the trouble we run into right now is because due to us wanting to
>> do good error messages, without any kind of a real parser, we
>> sometimes incorrectly split out what the function name is from the
>> rest of the line specification.
> 
> Either you're misunderstanding the case I'm trying to address, or I'm
> misunderstanding what find_toplevel_char is searching for. 

Well, find_toplevel_char is to find a comma at the top level, so we
can try to distinguish between "ranges" of lines, and function arguments.

This is because while we don't *care* about the function arguments
(since they aren't part of the symbol name), we do care about line
ranges.

The list command uses the line ranges, breakpoints don't support them.
But since they both use decode_line_1, we screw up the breakpoints for
the sake of something they don't support anyway (IE the whole "find
the toplevel comma" crap is pointless, since breakpoints don't support
line ranges).

Welcome to the wonders of improper code reuse.

Anyway, since it wanted to seperate out the first part of the line range from
the second, it attempts to find the comma to split it at. Which would
be the first comma at the top level.

Of course, since it didn't take < and > into account, it found a comma
in the middle of a template argument list, and boldly proclaimed:
"I've found the top level comma".

:)

Mind you, as i said, it's completely pointless for breakpoints.


> This is
> the kind of confusion that generates dozens of mail messages, but
> would take two seconds to straighten out in person.
> 
> Since the patch is approved either way (with appropriate changes to
> the comment above find_toplevel_char), and I think we all basically
> get what's going on, I'm not going to pursue this further.

I'm also about to submit a better patch, to replace the *breakpoint* parser
with a flex/bison parser.

That way, only the list command requires the evils of decode_line_1.
 

-- 
"I can remember the first time I had to go to sleep.  Mom said,
"Steven, time to go to sleep."  I said, "But I don't know how."
She said, "It's real easy.  Just go down to the end of tired and
hang a left."  So I went down to the end of tired, and just out
of curiosity I hung a right.  My mother was there, and she said
"I thought I told you to go to sleep."
"-Steven Wright