Re: [PATCH v4 6/9] Explicit locations: introduce explicit locations

[Matt Rice <ratmice@gmail.com>]

On Tue, May 26, 2015 at 9:42 PM, Doug Evans <xdje42@gmail.com> wrote:
> Keith Seitz <keiths@redhat.com> writes:
>> On 05/19/2015 03:14 PM, Pedro Alves wrote:
>>> On 05/19/2015 11:12 PM, Keith Seitz wrote:
>>>> On 05/19/2015 03:09 PM, Pedro Alves wrote:
>>>>
>>> OK, as long as
>>>
>>>   b -source 'file with spaces -line 10' -line 20
>>>
>>> works as expected (might be worth it of a test), the point is
>>> moot then.
>>
>> I think it does what is expected:
>>
>> (gdb) b -source 'file with spaces -line 10' -line 20
>> No source file named file with spaces -line 10.
>
> This error message needs to better delineate the file name.
> One could either put it in quotes (and escape internal quotes),
> or change it to something like:
> No such source file: file with spaces -line 10.
>
>> I'll add a test if one is missing. These "with spaces" tests appear in
>> ls-errs.exp and can be obscured by the fact that they test the parsing
>> by generating errors.
>
> I'm still really uneasy with supporting
> b -source file with spaces -line 20
>
> This is intended to be the low-level access to specifying locations.
> Low level APIs shouldn't be too concerned with easing typing.

hmm, I just thought of a 2nd pitfall:
in objective-c "b -method" I believe is a currently working linespec
to set breakpoints on all the instance methods name 'method' that
accept zero arguments.

thus there is the potential for collisions, the following header[1]
file declares a method on line 47: - (id) source; which should
currently be accepted via the linespec: 'b -source'

[1] https://github.com/gnustep/gui/blob/master/Headers/AppKit/NSNibConnector.h

> It's easier to relax restrictions than impose them after the fact.
> Can we require such files to be quoted today,
> and then later relax the restriction if there's a compelling
> reason to do so?