Re: Expressions Status and Oustanding Tasks

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> * Virtual methods table printing (print OBJ->VIRTFUNC) using
Keith> DW_AT_vtable_elem_location.

Keith> I don't know if anyone has addressed this at all. I know I
Keith> haven't. [I'm not even sure I completely understand what this task
Keith> is.] I presume that this is just a general item for virtual
Keith> class/methods.

I'm not sure I know what this one is either.  It may have come from
bugzilla ... anybody know?  If nobody knows, let's delete it from the
wiki.

Keith> Method overload resolution in the expression parser and
Keith> evaluator, e.g. "print foo(char*)".

This one is a bit odd because this is not C++ syntax.
It would be nice to have, unless it introduces ambiguity.

Keith> 2) Inferior function calls. No tests for this in realcpp yet. The big
Keith> item on this is the ability to call operators (especially anything
Keith> that might interfere with the expression parser in c-exp.y, like
Keith> operator+, operator(), operator[], operator<<, etc).

There is some operator overloading support already, but there are
cases where it doesn't work.  I don't know the details; but I assume
Koenig lookup is one missing piece.

Keith> 5) Contextual lookups. I meant to mention this in the meeting, but it
Keith> escaped my non-caffeinated mind. With all the work that has been on
Keith> the various expression "parsers", I've only worked in the global
Keith> scope, i.e., before the program is running. So realcpp does things
Keith> like "file mytestcase", "print foo::foo", and "list foo::foo". If we
Keith> now stop in a method in foo, I should be able to do "print/list/break
Keith> foo" and gdb should be able to figure out that "foo::" is
Keith> implied.

Yeah.  Basically we need to implement all the C++ name lookup rules.

Keith> 5a) Along the same lines, the completer needs attention: "complete
Keith> list foo::" returns a bunch of garbage in the global scope.

Nice -- I can't remember this coming up before, but it would be very
nice.

Keith> I think that's it; or at least, that's all I've discovered
Keith> right now. :-) Most of these things can be tackled in parallel
Keith> (except perhaps #3,4, but those need more investigation, and
Keith> perhaps a bit more justification).

Ok, good to know.  I'll update the wiki soon, and when someone needs a
new task we can look to see what remains.  As long as we have tasks
remaining that can be done in parallel, I think we should keep
plugging away at our original list.  When we're close to exhausting
this we can set our next list of goals.

Tom