Re: [RFA 7/9] Explicit locations v2 - CLI for explicit locations

[Keith Seitz <keiths@redhat.com>]

On 05/08/2014 05:48 PM, Matt Rice wrote:
> Just curious if we need this quote handling in explicit linespec's

Good question! I did this so long ago, I'm not 100% certain /why/ I 
chose to include quoting, but I can have a guess...

UI consistency. It is allowed in linespecs, largely -- but not entirely 
-- to work around (old) parser problems. Users are, sadly, quite used to 
quoting things. In order to maintain some sort of parallelism, I *think* 
that I added the ability to quote stuff, but it is not necessary (see 
below).

> I thought (though i'm not terribly familiar with c++ linespecs)
> that the quotes were for operator+, clashing with foo+offset
> and 'something::foo' clashing with file:line stuff,

With the "new" linespec parser, I've tried to minimize the need to quote 
anything. Alas, as you point out, the need still arises.

One of the tests that I have added for dprintfs seems to indicate that I 
had similar concerns about permissive quoting:

(gdb) dprintf -func A::operator,,"hello\n"

Believe it or not, that actually does do what it is supposed to do. [Ok, 
maybe I am the only one surprised to (re)discover that.]

> where it isn't obvious to me the need for it arises when using
> explicit locations.
> I suppose break -source '/path with spaces/foo.c' -line +42

I tried this on my working copy:

(gdb)  b -source /dir with spaces/file with spaces.c -line 3
No source file named /dir with spaces/file with spaces.c.
Make breakpoint pending on future shared library load? (y or [n]) n

So it seems I already had something in mind to handle spaces in a 
relatively sane way. [Not that there aren't any lurking bugs -- I'll be 
the first to admit I am seldom capable of writing bug-free code with a 
patch this large.]

> my main curiosity here is for languages which allow the ' character,
> particularly the ML family's usage of type variables[1]. to
> discriminate polymorphic functions of the variety break -function
> foo('a) vs break -function foo(string).

The parser seems to already permit this syntax, but again, I'm sure 
there are latent bugs in there somewhere:

(gdb) b -func foo('a)
Function "foo('a)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

So, in the end, it certainly seems that we could whack this quoting 
stuff altogether if it was so desired. Other than the parallelism 
`argument' that I think I used to justify this to myself when I 
originally wrote it, there isn't really a compelling reason to keep it. 
At least, not that I know of/remember right now.

Keith