Re: [Archer] Stop the Insanity! Linespec Rewrite

[Joel Brobecker <brobecker at adacore dot com>]

> Earlier this month, I dug this out of mothballs, and it is now time
> to submit the work-in-progress for comment. This is *not* a finished
> design and/or implementation! It is simply a place to stop along the
> road and ask for advice, for a fresh set of eyes. Consider this akin
> to an RFC.

I really like the fact that you're now splitting the parsing from the
evaluation (the transformation into SALs).

Looking at the parsing code, I had a feeling that it would not work
with Ada operators, and in particular with:

        (gdb) break "*"
        Argument required (expression to compute).

I then tried other operators that might be problematic, eg:

        (gdb) break "+"
        Function "+" not defined.
        Make breakpoint pending on future shared library load

But also simpler-to-handle operators such as "/" do not seem to work:

        (gdb) braek "/"
        Function "/" not defined.
        Make breakpoint pending on future shared library load

I reviewed the gdb.ada testsuite, and it appears that I failed to
add a testcase for those. I will put that on my list.

I can help with the implementation side of the above feature, but
do you think your parser could accomodate that? As discussed with
Tom, it is fine if we need to compromise a bit an accept "break *"
(the operator name without quotes) or "break '*'" (operator name
bracketed by single-quotes, which is illegal Ada, but who cares).

I have noticed a few other things:

  . Very minor: We now accept the "task" keyword in any casing (?).
    So now "break foo TASK 3" is accepted, whereas it wasn't in the past.

  . Your new linespec passes the entire gdb.ada testsuite. Congrats,
    this is no small feat, if you ask me!

  . Our testsuite spotted a couple of crashes. They might be related
    to the crash that Tom mentioned, although I kind of doubt it.
    Nevertheless, I'll investigate them after you've looked at Tom's
    report, just in case they end up having the same cause.

The code itself looks pretty good to me, although I mostly skimmed
through it. I agree with Tom that you can think of cleaning things up
and do an official submission. I'd like to resolve the issues mentioned
above before the patch actually goes in, but I have spare cycles next
week for that - let's enjoy those spares cycles while they last. They
have been pretty rare lately...

-- 
Joel