Re: disable objective-c stuff when theres no objective-c cu.

[Matt Rice <ratmice@gmail.com>]

On Wed, Oct 6, 2010 at 10:06 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> i could have argued this more concisely,
>> what I mean is that 'break' is not related to the current language,
>> but the language which we want to be the current language
>> when the breakpoint is hit.  and so 'set language' to use language
>> specific breakpoints is arguably wrong because the current language
>> may not be the language of the breakpoint we want set.
>
> But at the same time, I don't think we want to be able to support
> all languages at the same time.

yeah, thats what we currently do though, so this is a much larger
change of rewriting linespec i suppose.

> If we can guess the language of
> the location, great, but I think that's sort of a chicken-and-egg
> problem. You need to parse the location to determine the language,
> but you need to determine which language to use in order to parse it.
>
> IMO, it's much cleaner to follow the current-language when parsing
> the breakpoint location.  Various languages may want to provide
> bridges to other syntaxes (for instance, the Obj-C language might
> want to provide c-like breakpoint expressions), but I don't think
> that this should be part of the general code.  More particularly,
> I don't think that linespect should have to handle "break [foo]"
> when not in objc mode.

I'm alright with 'inferring' the linespec parsing based on the current
language I suppose, I just don't think that the user should have to
'set language objective-c' to set a breakpoint in a language which is
*not* the current language, because if the user were to subsequently
do
p foo
and the scope was a c++ class,
then it would look for self->foo instead of this->foo.

so if that means something like 'break objc:[something orOther]'
and being able to drop the objc: if the current language is objc thats ok IMO.