Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp713056pxx; Wed, 28 Oct 2020 15:16:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzed0K4gob3QQ+16XJ0UnvKdiNSmPCUy7cA+QAhllboT0cyYPMJmHSSZ6TWVv4tZWqdKvW2 X-Received: by 2002:a17:906:2e59:: with SMTP id r25mr1246540eji.520.1603923393312; Wed, 28 Oct 2020 15:16:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603923393; cv=none; d=google.com; s=arc-20160816; b=kg+dBZtGWtKTijayE8US8V+pETaK5RfbO63KNjCj7M/IISxVEcAN4idBWINkKDQTzM Kvupce+XfSc6QMhmHO7E/7ljL5kkSrS/LgHq/IeuHukpRFdZTmFv6TYdXzCUW/q/MrOZ 891dPOza2v2MbPaX14O7vN8ieaL52M40R0QH8EJqHFMmbg4uKaresW9J3AyL5//7m2zz 0tFeY74/Yzkdu7pmXaXy3ODtY9KQl8GHSKEV6axJJhwIt6ft4v7X2BQnZX2RkxEbEEa7 ZC8sj6KfTXTtTM323S63s3Wrf0kx2t1m/LbtkNUq9kHBwlDuPA4P0Yvm4HYsaiqa5nIa iS6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=1H/+XRuk87ocJVI4DFUJqadNY+HYTZRFdhQvIeG0Gcw=; b=ssEs1odOaAp4l7cvuu15s36Q83kO9X+56253O/THSLf8AafOIenJ7CoX5QrATzYuSx 3WYDwSkXnosEpgy3nywvAX/6DB8YITiQxHKi9qdFbYmrHu/hciGVS9O32IsIeXVm2vEF iIrJJ+6eStQvC3JAxaoC1ekI0wZOkOIU3eHwi1NH/2WEOKdcef42C7hVeXFsaOUYRo0e 9IwQQgIp2E7VMj92TqovvdvrfnZioZuX2huYdeqtxrdVp6kuB/uPEWUz/9m0JxubnZ9n o6vXd2HO2Psg4OwdyRFMbF8+i5vnkTAFRHdKCHG+U9nZjrujHyx318z/wiusAyqBhDTs v1MA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z69si669899ede.6.2020.10.28.15.16.05; Wed, 28 Oct 2020 15:16:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731316AbgJ1WPT (ORCPT + 99 others); Wed, 28 Oct 2020 18:15:19 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:51986 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731268AbgJ1WPG (ORCPT ); Wed, 28 Oct 2020 18:15:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A654929A58; Tue, 27 Oct 2020 23:26:19 -0400 (EDT) Date: Wed, 28 Oct 2020 14:26:12 +1100 (AEDT) From: Finn Thain To: Tom Rix cc: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com, linux-pm@vger.kernel.org, linux-crypto@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-iio@vger.kernel.org, linux-rdma@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-samsung-soc@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-nfs@vger.kernel.org, tipc-discussion@lists.sourceforge.net, alsa-devel@alsa-project.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: Re: [RFC] clang tooling cleanups In-Reply-To: <20201027164255.1573301-1-trix@redhat.com> Message-ID: References: <20201027164255.1573301-1-trix@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, 27 Oct 2020, trix@redhat.com wrote: > This rfc will describe > An upcoming treewide cleanup. > How clang tooling was used to programatically do the clean up. > Solicit opinions on how to generally use clang tooling. > This tooling is very impressive. It makes possible an idea that I had a while ago, to help make code review more efficient. It works like this. Suppose a patch, p, is the difference between the new tree, n, and the old tree, o. That is, p = n - o. Now let clang-tidy be the transformation 't'. This gets you a much more readable patch submission, P = t(n) - t(o). The only difficulty is that, if I submit P intead of p then 'git am' will probably reject it. This is solved by a little tooling around git, such that, should a patch P fail to apply, the relevant files are automatically reformatted with the officially endorsed transformation t, to generate a minimal cleanup patch, such that P can be automatically applied on top. If the patch submission process required* that every patch submission was generated like P and not like p, it would immediately eliminate all clean-up patches from the workload of all reviewers, and also make the reviewers' job easier because all submissions are now formatted correctly, and also avoid time lost to round-trips, such as, "you can have a reviewed-by if you respin to fix some minor style issues". * Enforcing this, e.g. with checkpatch, is slightly more complicated, but it works the same way: generate a minimal cleanup patch for the relevant files, apply the patch-to-be-submitted, and finally confirm that the modified files are unchanged under t.