Re: RFA: implement ambiguous linespec proposal

[Tom Tromey <tromey at redhat dot com>]

Joel> It is needed, and that's what we do at AdaCore. That's the new
Joel> canonical form that I was mentioning in the previous messages.
Joel> I don't think it is 100% unique, but it's pretty close, and I think
Joel> it's the best we can do (we've never heard reports of problems
Joel> with that form in the 10+ years we've been using it).

Joel> The canonical form for Ada is: FILE:FUNCTION_NAME:LINE_NO. Once
Joel> written in that form, the linespec parser should always re-evaluate
Joel> it into one single logical breakpoint (with potentially multiple
Joel> locations).

Oh, ok.  I forgot all the discussions we've had on this, maybe since I
was fixated on ada_lookup_symbol_list, or maybe because of sleep
deprivation :)

I think FILE:FUNCTION:LINE is a good form to provide to users, but it
seems to me that it is incorrect to rewrite a user's "FUNCTION" linespec
into this form.  My reason is that it seems like it would do the wrong
thing if the line number changes -- the linespec would stop working,
rather than re-evaluate correctly.  How do you deal with this problem?

My patch doesn't provide FILE:FUNCTION:LINE; but Keith is working on
some parsing changes for linespec that should make it simpler to add
things like this in the future.

Joel> The question is, can we use that same form for everyone? I thought
Joel> you were going to do unconditional rewriting of the location string,
Joel> but now I'm not so sure anymore...

With my patch, only relative forms require rewriting.  I think those are
just "break LINE" and "break LABEL".  The former is rewritten to
FILE:LINE, and the latter to FUNCTION:LABEL.

With multiple-symbols=ask, we also do filtering based on the "canonical
form", which is different from the string used to re-evaluate.

E.g., suppose you do "break something::method" and there are 5 methods.
Suppose you have multiple-symbols=ask and you pick something::method(int).
Then, we will have a breakpoint whose linespec is "something::method"
but whose filter is "something::method(int)".

I chose this somewhat odd design over the more straightforward rewriting
of the linespec because there are canonical forms which are not yet
suitable as input to linespec.  I could add these to linespec, but I
wanted to keep the patch smaller -- my plan is to update this once
Keith's changes are ready.

Tom