This is the mail archive of the
mailing list for the Archer project.
Re: Expressions Status and Oustanding Tasks
- From: Tom Tromey <tromey at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: archer at sourceware dot org
- Date: Thu, 26 Mar 2009 18:15:34 -0600
- Subject: Re: Expressions Status and Oustanding Tasks
- References: <49CA7CF3.firstname.lastname@example.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Keith" == Keith Seitz <email@example.com> writes:
Keith> * Virtual methods table printing (print OBJ->VIRTFUNC) using
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
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
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
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
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.