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 5E5C53858D33 for ; Tue, 7 Feb 2023 21:24:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5E5C53858D33 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=1675805074; 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=loBYa7xTgBGqulFrOdWTmrXBwRF84pjvfhp3rCBhh5Q=; b=V/3HFzZRq/Lp3+Lf1ypIf6E1HdKL6Ll9kSN5NTrNihBt2h+Xkya+7BqaFIN44ib6QS9sL+ +DKE7B3KigWMpP0f8hpmv0Wpy7GhBF10PmUgQWj7yIJnN3Ek/Hx7vaLX4627duwEZnRCUB 6RSxlm270REfi7fAEUG6xNC3Gk6bSa8= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-110-qOWdke3BN72DhHcb8GaVQQ-1; Tue, 07 Feb 2023 16:24:32 -0500 X-MC-Unique: qOWdke3BN72DhHcb8GaVQQ-1 Received: by mail-pj1-f70.google.com with SMTP id ob8-20020a17090b390800b00230e2b3dba3so2027725pjb.5 for ; Tue, 07 Feb 2023 13:24:32 -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=loBYa7xTgBGqulFrOdWTmrXBwRF84pjvfhp3rCBhh5Q=; b=c+SgOmkqps5g6LmM1n6L2X+9gbszR4HTuiN2MQhp0FzevWfb8Xo7GxS2cEDuzfuXsD 1Q99JVk0Tpbl9LUcgRJM0UJUew3sm76SWZ0vwnQDQ72H0PniqaSv79l5FFIEXw3t1o4O N6CC4JssqFdjcNDjo7TjJj22FJYSXBjathxz0UzvQ4tsys/GmHdVXLVXCTIe0r4rPREA X9hCc96/CFfkeNCKO8ybTKceMyjA0B7PBWTgh43CxNaWBCd34LpAudEwLgIuf4LaqMCG v13vSTliBFf2VZ9YJisaU/UbZd6xfEiVeyTlJQi9cFx2HRV7Cw8kUeFEvgaXCrOvAg7A +egQ== X-Gm-Message-State: AO0yUKVRNgrlmAOvW4uw9SQVUFG0GBKRSsKbed0OZ3D2f5vsRmQNmvYS H/QxQVFZ7Z0BcQ8Igeyi4DrwH0AjfeZoxrxW5P/ZfP9Bf7x0LE/VeSjWxSUgxn0azRlXTD0Ftg3 5jrL5qgIRJv0dJV4JR51rGNfAnNaKwN0= X-Received: by 2002:a17:90a:6a44:b0:230:b32a:bc9d with SMTP id d4-20020a17090a6a4400b00230b32abc9dmr149265pjm.17.1675805071406; Tue, 07 Feb 2023 13:24:31 -0800 (PST) X-Google-Smtp-Source: AK7set/QJWpYgQHBx6AmBFd1MFTCsrk8R+AXWmVD/zEwkrigncKIDboNtublyplmUywnoVdizO9hvJD48wMauyPe6Bo= X-Received: by 2002:a17:90a:6a44:b0:230:b32a:bc9d with SMTP id d4-20020a17090a6a4400b00230b32abc9dmr149261pjm.17.1675805071148; Tue, 07 Feb 2023 13:24:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Rodgers Date: Tue, 7 Feb 2023 13:24:20 -0800 Message-ID: Subject: Re: Add clang-format for libstdc++ To: Jonathan Wakely Cc: Dimitrij Mijoski , "libstdc++@gcc.gnu.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000faaafc05f422c54e" X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,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: --000000000000faaafc05f422c54e Content-Type: text/plain; charset="UTF-8" On Tue, Feb 7, 2023 at 1:20 PM Jonathan Wakely wrote: > 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. > > Thanks, I hate it. I'll add them with the upcoming PSTL rebase work. --000000000000faaafc05f422c54e--