From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id C51913857005 for ; Fri, 6 Nov 2020 17:11:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C51913857005 Received: from eggs.gnu.org ([2001:470:142:3::10]:38604) by fencepost.gnu.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kb5GN-0005Fn-LH for gcc-patches@gnu.org; Fri, 06 Nov 2020 12:11:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:57904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kb5GL-0003Hh-Vb for gcc-patches@gnu.org; Fri, 06 Nov 2020 12:10:59 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-510-SIjZm7olPDOi03k0byrsww-1; Fri, 06 Nov 2020 12:09:46 -0500 X-MC-Unique: SIjZm7olPDOi03k0byrsww-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA9F6188C12C; Fri, 6 Nov 2020 17:09:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-114-181.phx2.redhat.com [10.3.114.181]) by smtp.corp.redhat.com (Postfix) with ESMTP id A2A70261A6; Fri, 6 Nov 2020 17:09:42 +0000 (UTC) Subject: Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle. To: Nikhil Benesch , Eduard-Mihai Burtescu Cc: Ian Lance Taylor , gcc-patches References: <390716b0-6788-4350-8147-1dfc0c7a22ba@www.fastmail.com> <449bb241-a68e-c8e1-9960-1236a6384fc2@gmail.com> <35a48843-78f3-4a27-3706-ea8a75171ce6@gmail.com> <7f5bc1ea-39a9-4ad9-b518-84cd42e3046c@www.fastmail.com> <6f5e040a-ed4e-4860-874f-2e54c30b797c@www.fastmail.com> <81a4b570-a43e-4dab-a678-452fa9805699@www.fastmail.com> <4a19cc9c-04ae-a752-ad63-99812bca043d@gmail.com> From: Jeff Law Message-ID: Date: Fri, 6 Nov 2020 10:09:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <4a19cc9c-04ae-a752-ad63-99812bca043d@gmail.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: pass client-ip=216.205.24.124; envelope-from=law@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/06 07:11:31 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 17:11:02 -0000 On 11/1/20 10:26 AM, Nikhil Benesch via Gcc-patches wrote: > > > On 11/1/20 6:57 AM, Eduard-Mihai Burtescu wrote: >> Reading the diff patch, the v0 changes look great. I wouldn't be too >> worried >> about the "printable character" aspect, there are similar >> Unicode-related >> issues elsewhere, e.g. the "non-control ASCII" comment in >> decode_legacy_escape >> (I suppose we could make it also go through the "print a non-control >> ASCII >> character or some escape sequence" logic you added, if you think that >> helps). > > No, it's entirely fine with me! I just wasn't sure if the small > deviations in output were acceptable. It sounds like they are. So I think the best path forward is to let you and Eduard-Mihai make the technical decisions about what bits are ready for the trunk.  When y'all think something is ready, let's go ahead and get it installed and iterate on things that aren't quite ready yet. For bits y'all think are ready, ISTM that Eduard-Mihai should commit the changes. >> I can test the patch and upload the dataset tomorrow, but if you want >> to get >> something committed sooner (is there a deadline for the next >> release?), feel >> free to land the v0 changes (snprintf + const values) without the >> legacy ones. > > My understanding is that the GCC tree closes to new features on > November 16 (for "GCC 11 Stage 3"), but I'm not sure whether that > applies to libiberty or whether this patch would be classified as a > feature or a bugfix. > > I don't have commit rights (nor am I even a GCC developer). Just > wanted to tee things up for you and Ian this week. I'm very much > looking forward to the new demangling scheme and didn't want to be > just another +1 on the GitHub issue. > > So certainly no time pressure from me. But perhaps someone from the > GCC side can confirm whether we are under a bit of time pressure here > given the GCC 11 release. It's better to get it in sooner, but there is some degree of freedom depending on the impact of the changes.  Changes in the rust demangler aren't likely to trigger codegen or ABI breakages in the compiler itself -- so with that in mind I think we should give this code a higher degree of freedom to land after the stage1 close deadline. jeff