From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 68503385BF83 for ; Tue, 31 Mar 2020 19:15:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 68503385BF83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4A176116B2D; Tue, 31 Mar 2020 15:15:46 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wOF4rNr4zfwG; Tue, 31 Mar 2020 15:15:46 -0400 (EDT) Received: from murgatroyd (97-118-117-21.hlrn.qwest.net [97.118.117.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id D6CC5116B17; Tue, 31 Mar 2020 15:15:45 -0400 (EDT) From: Tom Tromey To: Tom Tromey Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] Avoid copying in lookup_name_info References: <20200320204935.19509-1-tromey@adacore.com> <20200320204935.19509-3-tromey@adacore.com> <87wo70baqu.fsf@tromey.com> X-Attribution: Tom Date: Tue, 31 Mar 2020 13:15:45 -0600 In-Reply-To: <87wo70baqu.fsf@tromey.com> (Tom Tromey's message of "Tue, 31 Mar 2020 13:11:21 -0600") Message-ID: <87a73wbaji.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-List-Received-Date: Tue, 31 Mar 2020 19:15:47 -0000 >>>>> "Tom" == Tom Tromey writes: Pedro> And if we do that, do we have any case where we really need the Pedro> "std::string &&" overload? Tom> Indeed we don't seem to need this. Actually, I am wrong, there is a spot in ada-lang.c: lookup_name_info name1 (std::string ("<_ada_") + name + '>', symbol_name_match_type::FULL); What's concerning is that this compiles even without the && overload, presumably by just violating the lifetime requirement of lookup_name_info. So, I think leaving the && version in-place is best. Tom