Re: [patch 0/3] Re: [RFA] c++/11734 revisited (and c++/12273)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> If the code should be nice I tried archer-jankratochvil-linespec where
Jan> linespec is based on the expressions.  Noted by Daniel Jacobowitz before:
Jan> 	http://sourceware.org/ml/gdb-patches/2009-11/msg00266.html

I think this would be a good direction to head.

One difficulty is that, right now, linespecs for one language often work
while the current language is set to something else.  This doesn't work
for Java, I think, but I think that is the point of the Objective C
hooks in linespec.c.

I'm not sure this is important enough that it is worth the maintenance
headache we have with linespecs.

Jan> It still has some regressions but the most common C++ cases work
Jan> there and I find it doable with some more time (mostly if the error
Jan> messages can be changed).

As long as the messages make sense to the user, I think the wording is
negotiable.

Jan>  The are problems with:
Jan>  * expression evaluator cares about the function value (=address) where the
Jan>    function symbol for linespec is already dropped.

Jan>  * linespec should have no side effects.  But the expression evaluator's
Jan>    EVAL_AVOID_SIDE_EFFECTS mode cares only about types, not about values.

It would be useful in other situations to be able to disable side
effects but still evaluate an expression.  I think there was a bug
report requesting this for GUIs, but I am not sure.

It would be nice if we could limit the parser to just consider names.
Maybe instead of evaluating the expression we could examine it and
extract the information we need from the parsed form.  Or, just make a
new language entry point and make each language do this internally.

Tom