This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/RFA] do not call decode_compound with Ada expressions.

> If linespec can't be language-independent, then IMO it should be calling
> methods on struct language_defn.  The current approach of examining the
> current_language is quite bad.  (And just to be clear, C++ is probably
> the worst offender here right now.)

Agreed. I am happy to transform the "if" into a call to language
method, if we can agree on the name and semantics.

> Joel> +	 /* We really should only be doing this for languages where
> Joel> +	    it actually makes sense.  For instance, Ada does not use
> Joel> +	    this type of syntax, and trying to apply this logic on
> Joel> +	    an Ada linespec may trigger a spurious error (for instance,
> Joel> +	    decode_compound does not like expressions such as `ops."<"',
> Joel> +	    which is a valid function name in Ada).  */
> Joel> +	  if (current_language->la_language != language_ada)
> There is a comment saying this is for C++ and Java.
> How about checking explicitly for those and nothing else?

That would work for me, but I'm concerned that we might be breaking
other languages which expect this to help (somehow) even when they
are using language C. For instance, I think obj-C developers rely on
being able to use obj-C linespecs even when the current language
is C.  This may be convenient for users, but a nightmare for us.
So, at a minimum, I would probably include c, c++, objc, java.
But why not minimal and asm? If the language is auto,asm, I think
users might expect the debugger to be able to understand C++ linespecs.
And now, looking at the list, I'm thinkig of including d, and maybe
opencl as well.

Given how quickly the list grew, perhaps it is better that we move
to using a language method straight away...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]