From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id EBA6E3858D1E for ; Fri, 11 Nov 2022 14:30:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBA6E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668177021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nGpBBE4FItLfYeMiXr2VTLw4w6oPDvpqqt5mn6RPD+c=; b=HZh3ZU1FuLJSkMZ8jbRN3QQfvMFhoGYtMNFZqQoY3eq4/Pm7+1UxFwhQxXA72CeUwQZfyk Qzvmmx9Yh0XyEIPzl/omh2aFF8pqjONG/u5SjBsX7Dy2DVe86mA/Tr156Zi08oLzmoyb+5 fNnxiLN4Kz2Fld2lyj1VrPy1NhNp4HA= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-214-fXOdDwxWNpeiMl_RDRRMwQ-1; Fri, 11 Nov 2022 09:30:20 -0500 X-MC-Unique: fXOdDwxWNpeiMl_RDRRMwQ-1 Received: by mail-qk1-f198.google.com with SMTP id bk30-20020a05620a1a1e00b006fb2378c857so4051790qkb.18 for ; Fri, 11 Nov 2022 06:30:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nGpBBE4FItLfYeMiXr2VTLw4w6oPDvpqqt5mn6RPD+c=; b=rS1HQKOadaaJ0r4kkgIiJ5ImMmS0OB2OeEWh3/rj0ZgScSPYT0rnEFVHXQNLz9PqBv MZZ4INgWB1yiEklIaPz7/ck+bkNK2AXo26gekbhv4bwpsQgQoYzCl0qV8wNMCTKFRlkR 35RQKK7URw3cSIa8xlhaapRgWfXYmFHZhyUW9yYnEV3OIFUHZlhTKko0vwAu3zNRk3+m T4/Eq9sXPZXUGXa60k0/xUi3vxcL22DN3bjJAGA/epaVu9/Iot33PBcDzJymSxqbuAwS e8M7039QedOrVoWV5OrSygKpN+xxevY/OsdoDXSMcrlOfXp003vf9VEl1TYvcCLCwSQQ oGsA== X-Gm-Message-State: ANoB5pnbA6YLp9VSRLNYV6A4WRUac0JYr9xnX5IYb5yglV5Ll1uiBJwL vcX1YCyU0hSA8hcXAK8mQpij74xpZij8Qoyh+zdJSYydgC5NiHgTAuIUZneeYCu3Bd6xQp9Psil 94grQxovsrfby9xa8OYElf43ijxI5s7nIxKx5vs/wTrz3lgmmCksZJczq38cuycA0j1auilyy8A == X-Received: by 2002:a05:6214:2e84:b0:4bb:717e:1462 with SMTP id oc4-20020a0562142e8400b004bb717e1462mr2030833qvb.49.1668177020020; Fri, 11 Nov 2022 06:30:20 -0800 (PST) X-Google-Smtp-Source: AA0mqf6QX+Y4RCePa0ivDn7h+W2OKuPKO77RmMBo4lO3BOqiwjCvMbckehMBGycnBJPKHb3/LjPPXg== X-Received: by 2002:a05:6214:2e84:b0:4bb:717e:1462 with SMTP id oc4-20020a0562142e8400b004bb717e1462mr2030818qvb.49.1668177019701; Fri, 11 Nov 2022 06:30:19 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id u3-20020a05622a198300b003999d25e772sm1323491qtc.71.2022.11.11.06.30.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 06:30:19 -0800 (PST) From: Andrew Burgess To: Bruno Larsen via Gdb-patches , gdb-patches@sourceware.org Cc: Bruno Larsen Subject: Re: [PATCH 2/2] gdb/c++: Detect ambiguous variables in imported namespaces In-Reply-To: <20221026155053.3394792-3-blarsen@redhat.com> References: <20221026155053.3394792-1-blarsen@redhat.com> <20221026155053.3394792-3-blarsen@redhat.com> Date: Fri, 11 Nov 2022 14:30:17 +0000 Message-ID: <87pmdta7ie.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.6 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 List-Id: Bruno Larsen via Gdb-patches writes: > 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 I suspect the exp_internal was added for debugging? Should this, and the 'exp_internal 0' line below be removed? Thanks, Andrew > 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" > -- > 2.37.3