From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107922 invoked by alias); 24 Dec 2018 17:30:38 -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 107832 invoked by uid 89); 24 Dec 2018 17:30:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=convinced, grammar, basis, expert X-HELO: mail-wm1-f48.google.com Received: from mail-wm1-f48.google.com (HELO mail-wm1-f48.google.com) (209.85.128.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Dec 2018 17:30:26 +0000 Received: by mail-wm1-f48.google.com with SMTP id a62so11619154wmh.4 for ; Mon, 24 Dec 2018 09:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qSdjRcsLVviFFUhYUkEnfHJIrd8cAjukkmtxFJ2kvlE=; b=dET4CGcdjLJ38C7dVWAnTwPfMPCAq89Otmt0o58pMTMdcruri2N9m0/8UbO3lyOl2F 6jGM5zmjCikYxaEEDGgii9xcrsUTSnAOUmbVPC/k/I4fL4d2LaYQvHVfan31eNsCe5zK T0rswFCEiS9RfkhiaSmkY5H0i+ARdrcTEW6HmivUVeBgyKI95qxpU5u1Fm2oVbXx3i3/ ltZQCby0lkHZPHXZJ6g/meSTNdfCCj3c6Njf1TiMCjNPRgxUElCiRWKFOU72yp+AJL0O WVyPIwbJFhcQk/SedunL8di5wp4GraqPhcS6/HyL2tn2aez/u0yRGQUTKp8JGJNvC3xY +j3g== Return-Path: Received: from localhost (host86-156-236-210.range86-156.btcentralplus.com. [86.156.236.210]) by smtp.gmail.com with ESMTPSA id s8sm23281244wrn.44.2018.12.24.09.30.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Dec 2018 09:30:22 -0800 (PST) Date: Mon, 24 Dec 2018 17:30:00 -0000 From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCHv2 0/4] gdb: Allow struct fields named double Message-ID: <20181224173021.GM3456@embecosm.com> References: <87tvjd4e54.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: Laetrile is the pits. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00304.txt.bz2 * Andrew Burgess [2018-12-18 22:40:09 +0000]: > Simon, Tom, > > Thanks for the feedback. > > * Tom Tromey [2018-12-16 09:42:15 -0700]: > > > >>>>> "Simon" == Simon Marchi writes: > > > > Simon> This looks reasonable to me, from the user point of view there is not reason > > Simon> why x.double would be different from x.float. With the same logic, we should > > Simon> also allow x.int, x.short, etc. But I'm fine with doing it on an as-needed basis. > > > > See also https://sourceware.org/bugzilla/show_bug.cgi?id=13368 > > The new patch series includes a patch that extends some of the > comments in order to hopefully address this bug. > > > > > Simon> This LGTM, with one thing below you might want to change. I'm far from an expert > > Simon> in parsers though, so please give others ~1 week to comment, and push then if you > > Simon> don't receive additional feedback. > > > > I think the main possible issue is if this introduces a new parser conflict. > > Taking a glance at the uses of "name" in the grammar, though, it seems > > safe enough. > > I took a better look at how the YACC step of the compile works, and it > turns out that parser conflicts are not fatal to the build, and my > change had introduced a new conflict. > > The new patch series addresses this by focusing my change specifically > on structure field names, so I want to be able to parse: > 'object.double', but I don't expect to be able to parse an object > named 'double'. I also extended my patch to cover other types like > 'int', 'short', etc. > > As penance I've included a patch that tweaks how pointers are parsed > that resolves 49 reduce/reduce conflicts. > > After this series there's still 42 shift/reduce conflicts, and 4 > reduce/reduce conflicts in the C parser, but patch #4, the one I > really care about, doesn't introduce any new conflicts. > > Tested on X86-64 GNU/Linux. > Tom, Thanks for the feedback on the revised patch series. I have gone ahead and pushed 1, 3, and 4, dropping patch 2. For patch #4 I confirmed there are no duplicate test names. In patch #2, you are correct and that the type stack is parsed in a slightly different order with the patch than before. I don't know if this is significant, but I certainly don't know that it's not. I'm convinced that patch #2 could be made to work, but I don't have time right now, so I'll add it to my ever-growing todo list. Thanks, Andrew