From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B29073858D38 for ; Tue, 7 Feb 2023 21:19:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B29073858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675804798; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pG4CmixaK9Ika3ZpyVdokev8BaXbWPhLOd/7n0aB1g0=; b=HxahUJkkfL+QhMvM9nZ20IS7g5KYzNeWZNWdE5U/eZ1T1fHmZeD7waAHchy42RfCgIHFCL ExSTtnWbJRxSUytKoqZEnRSHadKDsZhRLYmRWXB/exbHmE6VaahXwuzQD76OrEr0vZ8LSq jV5y+NfRtlvyQBuh88e3XqhCpLcB8H8= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-141-JgNcpK7OPbmVNYf072eKqA-1; Tue, 07 Feb 2023 16:19:57 -0500 X-MC-Unique: JgNcpK7OPbmVNYf072eKqA-1 Received: by mail-lf1-f71.google.com with SMTP id w2-20020a0565120b0200b004cfd8133992so6774572lfu.11 for ; Tue, 07 Feb 2023 13:19:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pG4CmixaK9Ika3ZpyVdokev8BaXbWPhLOd/7n0aB1g0=; b=idpxCim1GvkSlpFTiUybW61FiPPyVK1U6MizZBpzkcO7NyUAU1Qi0SJvbpnpV442uD zqcQ4L8YUGn2PXw0+k0zx6Ul9RM3terBAzpdGA6f158qq8TcGJqI1qstKGIcNu6Kxl2N YPEOjKLn9y2pA2hVxgvJCrb+nupJVcyOMTHJ0tV7BwJtXpoYCmzSM2hFGTN11vvj03Wr 8qKUDcS03vU1D2oP8ISpUcecxCz4dCvQzzYKqpYvyFC+4DBu0XbIuI9m1ywnlG8KMfGa K0hfNAER42tS580orVNJBiFSjfHEEfFk3ZlSHvRup0BIQeVrM0WFjoWQQvkmjpT0mJxR 1KQQ== X-Gm-Message-State: AO0yUKXgQuGNK9Y2WUuj9AXDPD7ZVl9A7aHL3rEKbzRZeQuTfO76cKKH j2MbmHo/tN8ap5PSVSWBh5UhBJJURoPUy/As8ey+45wm5aWTY9ub3IFuMnryPCm2Us/4v5Uxc3P pEgPUh3OLOW0a6+XfTOXv6Q5ZjbkY70k= X-Received: by 2002:ac2:5094:0:b0:4d8:58f0:b530 with SMTP id f20-20020ac25094000000b004d858f0b530mr852152lfm.2.1675804795645; Tue, 07 Feb 2023 13:19:55 -0800 (PST) X-Google-Smtp-Source: AK7set9URD5PbN1fLk7kDMPAHlJyPPHsyUICP4lEaRRthERSYxBLOVYvArFUnUbHV3mDIkdSRrzebV6YMWQpwIxOa+k= X-Received: by 2002:ac2:5094:0:b0:4d8:58f0:b530 with SMTP id f20-20020ac25094000000b004d858f0b530mr852149lfm.2.1675804795476; Tue, 07 Feb 2023 13:19:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Tue, 7 Feb 2023 21:19:44 +0000 Message-ID: Subject: Re: Add clang-format for libstdc++ To: Thomas Rodgers Cc: Dimitrij Mijoski , "libstdc++@gcc.gnu.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 7 Feb 2023 at 21:02, Thomas Rodgers via Libstdc++ wrote: > > I am potentially interested in this, with an additional twist - > > Is it possible to get clang-format to enforce the libstdc++ uglification > rules (probably requires a clang-format plugin though)? > > The concrete example I am thinking of here is when we adopt something like > the PSTL. It was a substantial manual effort to do the uglification on that > code in the first place, and despite multiple reviews by myself and > jwakely, we still managed to miss some identifiers. To complicate matters, > the upstream also makes ongoing changes while making a best effort to > preserve the uglifcation. They also miss some uglfications. The main > contributors in this case are shipping the PSTL as part of oneTBB and so > don't have the same requirements to 'get it right' as libstdc++, so this > often goes undetected. > > I am looking to rebase libstdc++'s PSTL in the near future so I'd be > willing to try something based on clang-format, if it existed, for this > particular purpose (I'm less interested in enforcing the indentation rules > in this case, as I want to preserve the upstream's formatting). > > I also think it is potentially useful to have both the uglification and > indentation combined. The case I'm thinking of is something like the > contribution (or ranges) which are similarly large and need to get the > uglification checks and in those cases, the correct libstdc++ formatting as > part of the adoption process. The best we have for this right now is the 17_intro/names.cc test. Names that are used in the PSTL (e.g. "binary_op", "exec", etc.) should be added to that file, so that if they appear without the "__" prefix we get test failures.