This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix c++/14819 (implicit this)
- From: Tom Tromey <tromey at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: "gdb-patches\ at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Fri, 15 Nov 2013 10:48:12 -0700
- Subject: Re: [RFA] Fix c++/14819 (implicit this)
- Authentication-results: sourceware.org; auth=none
- References: <52795E6A dot 2050506 at redhat dot com> <87vc05o28v dot fsf at fleche dot redhat dot com> <52841CD1 dot 1080401 at redhat dot com>
>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
Keith> I'm not entirely sure it is possible to actually get EVAL_SKIP
Keith> here (EVAL_AVOID_SIDE_EFFECTS is handled already), but I've
Keith> changed it to "bail" if we see anything other than EVAL_NORMAL.
Yeah. Ideally I think we wouldn't let EVAL_* escape eval.c. Not your
problem though.
Keith> So I've added a new function, find_type_baseclass_by_name which
Keith> searches the base classes of the given type for a base class of the
Keith> given name. Calling this in classify_inner_name in the appropriate
Keith> places "makes everything work." (TM)
This seems like a fine idea to me.
Keith> + /* cp_lookup_nested_symbol might have accidentally found a constructor
Keith> + named COPY when we really wanted a base class of the same name.
Keith> + Double-check this case by looking for a base class. */
Keith> + {
Keith> + struct type *base_type = find_type_baseclass_by_name (type, copy);
Keith> +
Keith> + if (base_type != NULL)
Keith> + {
Keith> + yylval.tsym.type = base_type;
Keith> + return TYPENAME;
Keith> + }
I wonder what happens here if you actually do want the constructor.
Like "print B::B". Will it still find the baseclass?
Keith> +/* Search through the base classes of PARENT_TYPE for a base class
Keith> + named NAME and return its type. If not found, return NULL. */
Keith> +
Keith> +struct type *
Keith> +find_type_baseclass_by_name (struct type *parent_type, const char *name)
Keith> +{
Keith> + int i;
Keith> +
Keith> + for (i = 0; i < TYPE_N_BASECLASSES (parent_type); ++i)
Probably this function requires check_typedef sprinkled liberally
around.
Keith> + {
Keith> + struct type *type = TYPE_BASECLASS (parent_type, i);
Keith> + const char *base_name = TYPE_BASECLASS_NAME (parent_type, i);
Keith> +
Keith> + if (base_name == NULL)
Keith> + continue;
Keith> +
Keith> + if (streq (base_name, name))
Keith> + return type;
It is possible to have ambiguous base classes?
And if so, where is that diagnosed?
Another horrible thought is what does "this->typedef_name::field" mean?
Anything? What is typedef_name is a typedef for one of the base classes?
Keith> +gdb_test "print D::i" "Cannot reference non-static field \"i\""
Keith> +gdb_test "print D::i" "= 4"
Duplicated test names.
I think there are more than one.
It's fine to just wrap the sequences in with_test_prefix though.
Tom