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.133.124]) by sourceware.org (Postfix) with ESMTPS id 094D33858CDA for ; Tue, 7 Feb 2023 21:01:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 094D33858CDA 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=1675803698; 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=obAIKe3CS3b4RimLoc1tT82gSYZIteg8kgDWPPq75qY=; b=SSzhE4XC7/e76gpigzLYNUmjfG7jp3Idk5aSpu4fKNLzrH2211F434vKh4hKzbsAeapk3x bHOKIEgf7gZnO2/bsE4Z4mKK1Jf2BZxPXu+kuCaYuq2ncd9/EhbrC3QxGoHi1Gv5aagYv5 Xsa/MYKy1/UEC/h1xVAqjXCe8S8NlZc= Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-280-oq0MiNj4N4iikDDRLIoefg-1; Tue, 07 Feb 2023 16:01:37 -0500 X-MC-Unique: oq0MiNj4N4iikDDRLIoefg-1 Received: by mail-pg1-f199.google.com with SMTP id bj12-20020a056a02018c00b004fac0fa0f9eso3634000pgb.19 for ; Tue, 07 Feb 2023 13:01:37 -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=obAIKe3CS3b4RimLoc1tT82gSYZIteg8kgDWPPq75qY=; b=mJmIKT2ue336uZZ0IVBj+P+1rXES8LG2ChI+3j06GkcHUcFA9X15Ldz3tUfxGM0Zdj 060QHRWVc2s2drxNmOXiYSNeJ99NGgzEWJz5Vo5/hk2nVKfrSPvvWNM1+zJqKKuY5NSz cEfXmESNMkwEsz3cl/Nc+uCgu/YgsQJy3c/U+AzwBgn0kV4XqvnKsKbsLptFYS7D09yK 5shtzN4G9qqITNK4+tssnFJy68xeghcY8ncNMTCaG4fj3LYYx73ZFS8PnqlQz1sF/P3a T6MRy/wa66kuIZ3xxaQ+4eK/wsrrFUJk5HLNTdqChSQhZojDPBih5kXLGv2PawqVlDQJ EFpA== X-Gm-Message-State: AO0yUKUQErhYJcSW8oXyLPZTc3w51P6lQcvAs4IGm78r1aP+2sM0AVkf WEp9+AxuuG5KoFtpHwLkwyyrk6dmJIMrI38QwcNIFa3/i2e5SDwTrI6KKoA9EYM5XEQ514Qkhwv 5ikedd9Htya4AtvxCecP0sWqED2guZ1c= X-Received: by 2002:a17:902:7c8e:b0:198:ef8f:4d89 with SMTP id y14-20020a1709027c8e00b00198ef8f4d89mr1141337pll.15.1675803696201; Tue, 07 Feb 2023 13:01:36 -0800 (PST) X-Google-Smtp-Source: AK7set/cYTaYoR9CzQai0wLzmT2k3C0N2EPAvHTl5ix8f7hTe0vTNT0LPyJPaU1sDh8MO4tjocv98nYvbE+CuU1wf3s= X-Received: by 2002:a17:902:7c8e:b0:198:ef8f:4d89 with SMTP id y14-20020a1709027c8e00b00198ef8f4d89mr1141329pll.15.1675803695648; Tue, 07 Feb 2023 13:01:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Rodgers Date: Tue, 7 Feb 2023 13:01:24 -0800 Message-ID: Subject: Re: Add clang-format for libstdc++ To: Dimitrij Mijoski Cc: "libstdc++@gcc.gnu.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000fe2e9d05f4227397" X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_SHORT,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: --000000000000fe2e9d05f4227397 Content-Type: text/plain; charset="UTF-8" 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. On Tue, Feb 7, 2023 at 12:39 PM Dimitrij Mijoski via Libstdc++ < libstdc++@gcc.gnu.org> wrote: > Is there interest to add a clang-format file for libstdc++? > > The basic idea is to take the existing clang format located at > contrib/clang-format, > copy it to contrib/clang-format-libstdc++, and modify it according to > libstdc++ rules > https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html . > Similarly to the first clang-format, it will be optional and it will be > enabled if the developer > calls the command: > > make clang-format > > inside the build tree. That will create the symbolic link > srcdir/libstdc++-v3/.clang-format . > Alternatively, it can be put directly where it is required without the > need for the invocation > of make. > > --000000000000fe2e9d05f4227397--