From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-56495-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 17056 invoked by alias); 6 Jun 2008 10:28:13 -0000
Received: (qmail 17048 invoked by uid 22791); 6 Jun 2008 10:28:12 -0000
X-Spam-Check-By: sourceware.org
Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jun 2008 10:27:53 +0000
Received: from HOME-C4E4A596F7 ([83.130.2.23]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K2100F2TF2MHNJ0@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Fri, 06 Jun 2008 13:42:45 +0300 (IDT)
Date: Fri, 06 Jun 2008 10:28:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [RFA] Patch to limit field name completion candidates
In-reply-to: <m3ej7bb7zi.fsf@fleche.redhat.com>
X-012-Sender: halo1@inter.net.il
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <uej7ac0z7.fsf@gnu.org>
References: <m38wyf6py1.fsf@fleche.redhat.com> <20080605170952.GJ29085@caradoc.them.org> <m3k5h3d6xt.fsf@fleche.redhat.com> <20080605194553.GG25085@caradoc.them.org> <m3bq2fd4zl.fsf@fleche.redhat.com> <20080605200807.GJ25085@caradoc.them.org> <m3mylzbd6o.fsf@fleche.redhat.com> <20080606023129.GB23233@caradoc.them.org> <m3ej7bb7zi.fsf@fleche.redhat.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2008-06/txt/msg00109.txt.bz2

> From: Tom Tromey <tromey@redhat.com>
> Date: Thu, 05 Jun 2008 20:41:21 -0600
> 
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
> Daniel> You don't recurse into base classes... for C++ this is
> Daniel> obviously a substantial problem.
> 
> Thanks -- I will look at this.
> 
> Daniel> Then there's the additional question of dynamic type.
> 
> I did think about this one, but forgot to mention it.
> 
> I don't see a good way to make it work in general.  It could be made
> to work sometimes, but not always.  In particular I think we could add
> a "don't evaluate side effects" mode to expression evaluation -- this
> would do an ok job except for the case of an expression involving an
> inferior function call.  In that case I think we could still only use
> the static type.

These limitations should be mentioned in the manual, at least as a
@footnote, I think.