From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-ss-820.bluehost.com (outbound-ss-820.bluehost.com [69.89.24.241]) by sourceware.org (Postfix) with ESMTPS id 2DB18385802F for ; Fri, 18 Nov 2022 20:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2DB18385802F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw15.mail.unifiedlayer.com (unknown [10.0.90.130]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id 39021100479D8 for ; Fri, 18 Nov 2022 20:33:31 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id w83Go8UQgjKFBw83HoOWOv; Fri, 18 Nov 2022 20:33:31 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=RYpVt3hv c=1 sm=1 tr=0 ts=6377ec1b a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=9xFQ1JgjjksA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=t-RiTUX4Wmcez3TnGCgA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7W4i10Mp0NAnjh/xePVyPhNb6g1MNWbQXVbfRLKwEYE=; b=trI47vhBp4LEkOjlcwRXX1wcxV t9Lrce6s+hq/q6lNoWol/mmf06OrA337lm+hbd/vnKPP/JjHSNoMbj9dXvAtMgvxLDc8P2oKEh+Jq vAHEyL7dRmvNzQWXDlbDu6bT9; Received: from 97-122-76-186.hlrn.qwest.net ([97.122.76.186]:56880 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ow83G-002hCY-M0; Fri, 18 Nov 2022 13:33:30 -0700 From: Tom Tromey To: Felix Willgerodt via Gdb-patches Cc: Felix Willgerodt Subject: Re: [PATCH 1/1] gdb: Enable complete to show members of anonymous classes/structs. References: <20220906072153.508130-1-felix.willgerodt@intel.com> X-Attribution: Tom Date: Fri, 18 Nov 2022 13:33:28 -0700 In-Reply-To: <20220906072153.508130-1-felix.willgerodt@intel.com> (Felix Willgerodt via Gdb-patches's message of "Tue, 6 Sep 2022 09:21:53 +0200") Message-ID: <877czsq9yf.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.76.186 X-Source-L: No X-Exim-ID: 1ow83G-002hCY-M0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-76-186.hlrn.qwest.net (murgatroyd) [97.122.76.186]:56880 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3022.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Felix" == Felix Willgerodt via Gdb-patches writes: Hello. Thank you for the patch. I'm sorry it took so long to review, but I appreciate your persistence in pinging it. Felix> After: Felix> ~~~ Felix> (gdb) p unique_name_foo Felix> $1 = 5 Felix> (gdb) complete p unique_name_fo Felix> p unique_name_foo Felix> (gdb) Felix> ~~~ The outcome seems like what we want. Felix> As we are able to print the member we should be able to complete on it. Felix> GDB doesn't look at "this" and its members for complete, while it does Felix> when printing. So I tried fixing that. Felix> I saw that "this" is always represented as a PTR type with the symbol Felix> class LOC_COMPUTED (with g++ 11.3.1, clang++ 10.0.1 and icpx 2022.1). Felix> Not knowing too much about LOC_COMPUTED, I am assuming that this is the right Felix> symbol class for this case and that we should adjust Felix> completion_list_add_fields() for it. Felix> But it could very well be that I missed something. Any comments welcome! I don't think there's any requirement that 'this' be LOC_COMPUTED. LOC_COMPUTED just means that the symbol's address is computed via some function call (normally into the DWARF code to handle an exprloc). However, nothing says it couldn't be LOC_REGISTER or LOC_ARG or something. Felix> + if (sym->aclass () == LOC_TYPEDEF Felix> + || (sym->aclass () == LOC_COMPUTED && t->code () == TYPE_CODE_PTR)) It seems like this could match many local symbols -- like, nearly any local variable that has pointer type. But, completing on these fields is not desirable; instead you only want to examine 'this'. Instead you probably want something like what lookup_symbol_aux does: if (is_a_field_of_this != NULL && domain != STRUCT_DOMAIN) { result = lookup_language_this (langdef, block); if (result.symbol) That is, use the current language (or in this case perhaps some search language, I don't really know) to find the name of 'this', then use it if this symbol matches. Probably this should be done in the caller to avoid a lot of repeated calls. Felix> + for (int j = TYPE_N_BASECLASSES (t); j < t->num_fields (); j++) Felix> if (t->field (j).name ()) Felix> completion_list_add_name (tracker, sym->language (), To me this loop looks incomplete, because it seems like it ought to walk over superclasses as well. Not your bug but if you really want this to work correctly, it's worth fixing (and adding a test for). Tom