From patchwork Wed Oct 26 15:50:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Guinevere Larsen X-Patchwork-Id: 59488 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D75DD382A2F2 for ; Wed, 26 Oct 2022 15:59:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D75DD382A2F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666799951; bh=r30dkI4oYRkTvqyeZvoCi87mnpZ4aZhwK6zsXqj/qGw=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=jsq49Ws6mn7G/bNn8Dmt/o9/V8fNoB6JiSO5qUWQH6F37ecTf1Gnke8DrNey4tor5 iDWq3ZLU/xbYsYgNcG9ECIDmB2z4leI3UFXrW0Zqo4d+ljg32smCsUKH9BMpci1KYY l3Xjy/ZQ1TFnKr1y//aDgmhtdxNE4zIGs4Cqzr44= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 601A0382DE07 for ; Wed, 26 Oct 2022 15:57:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 601A0382DE07 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-245-F0ZLsq1TPV6H1sOkeQb-oQ-1; Wed, 26 Oct 2022 11:57:39 -0400 X-MC-Unique: F0ZLsq1TPV6H1sOkeQb-oQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4E6E51C1A545 for ; Wed, 26 Oct 2022 15:57:39 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.22.33.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D8EBB1121339; Wed, 26 Oct 2022 15:57:38 +0000 (UTC) To: gdb-patches@sourceware.org Cc: Bruno Larsen Subject: [PATCH 2/2] gdb/c++: Detect ambiguous variables in imported namespaces Date: Wed, 26 Oct 2022 17:50:54 +0200 Message-Id: <20221026155053.3394792-3-blarsen@redhat.com> In-Reply-To: <20221026155053.3394792-1-blarsen@redhat.com> References: <20221026155053.3394792-1-blarsen@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Bruno Larsen via Gdb-patches From: Guinevere Larsen Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB will print M::x, and using clang 16.0.0 prints N::x. Not only is this behavior confusing to users, it is also not consistent with compiler behaviors, which would warn that using x is ambiguous at this point. This commit makes it so instead of exiting early when finding any symbol with the correct name, GDB continues searching through include directives until it finds another symbol with the same name but a different mangled name - returning an ambiguous variable - or goes through all imported namespaces and returns zero or one matching symbols. The commit also changes gdb.cp/nsusing.exp to test the ambiguous detection. --- gdb/cp-namespace.c | 35 ++++++++++++++++++++++++++++---- gdb/testsuite/gdb.cp/nsusing.exp | 19 +++++++++++++---- 2 files changed, 46 insertions(+), 8 deletions(-) diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c index c1b6978b7c8..7a07a8dbe75 100644 --- a/gdb/cp-namespace.c +++ b/gdb/cp-namespace.c @@ -383,6 +383,8 @@ cp_lookup_symbol_via_imports (const char *scope, { struct using_direct *current; struct block_symbol sym = {}; + struct block_symbol saved_sym = {}; + const char* sym_name = nullptr; int len; int directive_match; @@ -392,7 +394,11 @@ cp_lookup_symbol_via_imports (const char *scope, block, domain, 1); if (sym.symbol != NULL) - return sym; + { + saved_sym = sym; + sym_name = saved_sym.symbol->m_name; + sym = {}; + } /* Due to a GCC bug, we need to know the boundaries of the current block to know if a certain using directive is valid. */ @@ -446,7 +452,16 @@ cp_lookup_symbol_via_imports (const char *scope, if (declaration_only || sym.symbol != NULL || current->declaration) { if (sym.symbol != NULL) - return sym; + { + if(sym_name == nullptr) + { + saved_sym = sym; + sym_name = saved_sym.symbol->m_name; + sym = {}; + } + else if (strcmp(sym_name, sym.symbol->m_name) != 0) + error (_("reference to \"%s\" is ambiguous"), name); + } continue; } @@ -479,11 +494,23 @@ cp_lookup_symbol_via_imports (const char *scope, } if (sym.symbol != NULL) - return sym; + { + if(sym_name == nullptr) + { + saved_sym = sym; + sym_name = saved_sym.symbol->m_name; + sym = {}; + } + else if (strcmp(sym_name, sym.symbol->m_name) != 0) + error (_("reference to \"%s\" is ambiguous"), name); + } } } - return {}; + if (sym_name != nullptr) + return saved_sym; + else + return {}; } /* Helper function that searches an array of symbols for one named NAME. */ diff --git a/gdb/testsuite/gdb.cp/nsusing.exp b/gdb/testsuite/gdb.cp/nsusing.exp index bce6e30adc1..363ae862953 100644 --- a/gdb/testsuite/gdb.cp/nsusing.exp +++ b/gdb/testsuite/gdb.cp/nsusing.exp @@ -123,15 +123,26 @@ if { [test_compiler_info {gcc-[0-3]-*}] || return } + # GCC doesn't properly set the decl_line for namespaces, so GDB believes + # that both using directives are valid as long as we are in this scope. +exp_internal 1 gdb_test_multiple "print x" "print x, before using statement" { -re -wrap "No symbol .x. in current context.*" { pass $gdb_test_name } - # GCC doesn't properly set the decl_line for namespaces, so GDB believes - # that the "using namespace M" line has already passed at this point. - -re -wrap "= 911.*" { + -re -wrap "reference to .x. is ambiguous.*" { xfail $gdb_test_name } } +exp_internal 0 gdb_test "next" ".*" "using namespace M" -gdb_test "print x" "= 911" "print x, only using M" +gdb_test_multiple "print x" "print x, only using M" { + -re -wrap "= 911.*" { + pass $gdb_test_name + } + -re -wrap "reference to .x. is ambiguous.*" { + xfail $gdb_test_name + } +} +gdb_test "next" ".*" "using namespace N" +gdb_test "print x" "reference to .x. is ambiguous" "print x, with M and N"