Re: RFA: implement ambiguous linespec proposal

[Tom Tromey <tromey at redhat dot com>]

Jan> -PASS: gdb.cp/ovsrch.exp: break outer::foo if (a == 3)
Jan> +FAIL: gdb.cp/ovsrch.exp: break outer::foo if (a == 3)
Jan> -PASS: gdb.cp/ovsrch.exp: break inner::foo if (a == 3)
Jan> +FAIL: gdb.cp/ovsrch.exp: break inner::foo if (a == 3)

Tom> I don't like how this test assumes that gdb will do a namespace search
Tom> for a symbol when decoding linespecs.  That just seems wrong to me.
Tom> But, we've shipped it for a while, so I think we'll have to cope.

I am not sure we can make this work sanely.  I'm tempted to declare
these tests invalid and remove them.

Consider this program:

    namespace N1 {
      int m() { return 23; }
    };

    namespace N2 {
      int m() { return 23; }
    };

    int main()
    {
      using namespace N1;
      using namespace N2;
      return 0;
    }

I think this is valid (g++ accepts it).

What should gdb do if we are stopped in 'main' and the user types 'break m'?


Doing namespace searches is a problem if they yield an ambiguous result
because either:

1. There is no canonical name that can be put into the breakpoint for
   resetting, or

2. The breakpoint would have to also capture the current block for
   re-setting, which opens a whole new set of problems.


I understand that the rationale here is for gdb to work like the
compiler does.  And, I still think that makes a lot of sense for
expressions.  But for linespecs I am not convinced, as I think they are
different in nature: they may be re-parsed in many different contexts
and they may apply across objfiles and program spaces.  Also, for C++ at
least, I think "work like the compiler" will have more awful
implications: ADL, template stuff, ... I would rather just require the
user to type what they mean.

Tom