From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90605 invoked by alias); 25 Jan 2018 16:00:35 -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 90383 invoked by uid 89); 25 Jan 2018 16:00:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1139 X-HELO: gateway21.websitewelcome.com Received: from gateway21.websitewelcome.com (HELO gateway21.websitewelcome.com) (192.185.46.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Jan 2018 16:00:05 +0000 Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 254A2402F9619 for ; Thu, 25 Jan 2018 10:00:04 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id ejwaeqT4vzzFjejwaeWCon; Thu, 25 Jan 2018 10:00:04 -0600 Received: from 71-218-90-63.hlrn.qwest.net ([71.218.90.63]:44756 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eejwZ-0022SD-Ra; Thu, 25 Jan 2018 10:00:03 -0600 From: Tom Tromey To: "Leszek Swirski via gdb-patches" Cc: Leszek Swirski Subject: Re: [PATCH v2] Do not classify C struct members as a filename References: <20180124165107.186980-1-leszeks@google.com> Date: Thu, 25 Jan 2018 16:00:00 -0000 In-Reply-To: <20180124165107.186980-1-leszeks@google.com> (Leszek Swirski via gdb-patches's message of "Wed, 24 Jan 2018 16:51:07 +0000") Message-ID: <87zi52gc8u.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1eejwZ-0022SD-Ra X-Source-Sender: 71-218-90-63.hlrn.qwest.net (pokyo) [71.218.90.63]:44756 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-01/txt/msg00532.txt.bz2 >>>>> "Leszek" == Leszek Swirski via gdb-patches writes: Leszek> There is existing logic in C/C++ expression parsing to avoid classifying Leszek> names as a filename when they are a field on the this object. This Leszek> change extends this logic to also avoid classifying names after a Leszek> struct-op (-> or .) as a filename, which otherwise causes a syntax Leszek> error. Nice, thanks for doing this. Leszek> - if (parse_completion && tokentab2[i].token == ARROW) Leszek> + if (tokentab2[i].token == ARROW) Leszek> - if (parse_completion) Leszek> - last_was_structop = 1; Leszek> + last_was_structop = 1; This change makes sense (and thanks for updating that comment as well), but I wonder whether this changes the behavior in some case. Elsewhere in lex_one_token there is a check of saw_structop: else if (saw_structop) return COMPLETE; Previously this return could only be taken if parse_completion was set, but now I think it could be taken in other situations. So, I suspect "parse_completion &&" should be stuck in there. Tom