From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122511 invoked by alias); 14 Jul 2017 21:45:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 122467 invoked by uid 89); 14 Jul 2017 21:45:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=commas, balanced, laid X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Jul 2017 21:45:50 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 27955806BA for ; Fri, 14 Jul 2017 21:45:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 27955806BA Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=keiths@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 27955806BA Received: from valrhona.uglyboxes.com (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E47B1619EE; Fri, 14 Jul 2017 21:45:47 +0000 (UTC) Subject: Re: [PATCH 17/40] Linespec lexing and C++ operators To: Pedro Alves , gdb-patches@sourceware.org References: <1496406158-12663-1-git-send-email-palves@redhat.com> <1496406158-12663-18-git-send-email-palves@redhat.com> From: Keith Seitz Message-ID: <59693B8B.6030205@redhat.com> Date: Fri, 14 Jul 2017 21:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1496406158-12663-18-git-send-email-palves@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00206.txt.bz2 On 06/02/2017 05:22 AM, Pedro Alves wrote: > There's some lexing code in linespec that isn't handling C++ operators > correctly. It's the usual confusion with operator< / operator<<, in > code that wants to skip past template parameters. > > The linespec_lexer_lex_string change is necessary otherwise we get > this (with current master): > > (gdb) break 'operator<' > unmatched quote > > The need for the find_toplevel_char change was exposed by the use of > that function in the explicit location completer. Without the fix, > that completer is not able to "see" past operator< symbols, without > quoting, like: > > (gdb) b -function operator<(int, int) -labe[TAB] # nothing happens > > gdb incorrectly thinks "-labe" is part of the "unclosed" template > parameter list started with "<". Ouch. The best laid plans... Just a few trivial things. > diff --git a/gdb/linespec.c b/gdb/linespec.c > index 0216bf1..f24cca2 100644 > --- a/gdb/linespec.c > +++ b/gdb/linespec.c > @@ -674,14 +674,49 @@ linespec_lexer_lex_string (linespec_parser *parser) > else if (*PARSER_STREAM (parser) == '<' > || *PARSER_STREAM (parser) == '(') > { > - const char *p; > + /* Don't interpret 'operator<' / 'operator<<' as a > + template parameter list though. */ > + if (*PARSER_STREAM (parser) == '<' > + && (PARSER_STATE (parser)->language->la_language > + == language_cplus) > + && (PARSER_STREAM (parser) - start) >= CP_OPERATOR_LEN) > + { > + const char *p = PARSER_STREAM (parser); > + > + while (p > start && isspace (p[-1])) > + p--; > + if (p - start >= CP_OPERATOR_LEN) > + { > + p-= CP_OPERATOR_LEN; This is a cut-n-paste-o (that's a typo propagated via cut-n-paste). Missing a space before the operator. > + if (strncmp (p, CP_OPERATOR_STR, CP_OPERATOR_LEN) == 0 > + && (p == start > + || !(isalnum (p[-1]) || p[-1] == '_'))) > + { > + /* This is an operator name. Keep going. */ > + ++(PARSER_STREAM (parser)); > + if (*PARSER_STREAM (parser) == '<') > + ++(PARSER_STREAM (parser)); > + continue; > + } > + } > + } > > - p = find_parameter_list_end (PARSER_STREAM (parser)); > - if (p != NULL) > + const char *p = find_parameter_list_end (PARSER_STREAM (parser)); > + PARSER_STREAM (parser) = p; > + > + /* Don't loop around to the normal \0 case above because > + we don't want to misinterpret a potential keyword at > + the end of the token when the string isn't > + "()<>"-balanced. This handles "b > + function(thread" in completion mode. */ > + if (*p == '\0') > { > - PARSER_STREAM (parser) = p; > - continue; > + LS_TOKEN_STOKEN (token).ptr = start; > + LS_TOKEN_STOKEN (token).length = PARSER_STREAM (parser) - start; Line length > 80? > + return token; > } > + else > + continue; > } > /* Commas are terminators, but not if they are part of an > operator name. */ Keith