From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D785BC63697 for ; Tue, 27 Oct 2020 16:43:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 89D2721707 for ; Tue, 27 Oct 2020 16:43:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SbUT6LrP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1811899AbgJ0Qn0 (ORCPT ); Tue, 27 Oct 2020 12:43:26 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:59410 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1811885AbgJ0QnU (ORCPT ); Tue, 27 Oct 2020 12:43:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603816998; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=SbUT6LrPKSG/kjhEPSpbNL37X7EqS95pLWLFJN05U8T6IvmsgoI1621azrkHaUCQe2IU+4 A+8ip+R7TFhvfL2PFtA2YPAVSij+jMd+5zp3Ro8XdkS11BXJM1Rlv3U/dAVL3h95weU9IY Ml5NELPo7a9T9EfhM60DKYJDO3/RVn0= Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-121-o1Hcd2IYMXiizB5EhdgrzQ-1; Tue, 27 Oct 2020 12:43:14 -0400 X-MC-Unique: o1Hcd2IYMXiizB5EhdgrzQ-1 Received: by mail-oi1-f197.google.com with SMTP id k16so427263oik.6 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=QS0M9KVw2jnB/VCXe5s0ePqdfrP6VTF2ETN02XqCtPuPbZxP1Fq2mWY2euQDpJiKho e95VjHQIYg5Fbu7zE+jaPr5OST513F6hhStsV/RtQuVLBMPhtW+f6oXJtkoCkztqXDFm 65xHLeRQcvxKOvZL0CJKN9KxiN2zxx47YcJTsTPmWKozPfAXurmHGzXUvQBc4K9bTzbl 6/aiW5ZZEyyOzL+F1Ca8juhcSCaBKipjlza049ud5hUb7+lCyu5YaNjLDTDOXd7qdyhz 1g2Axs36xdGz5dlpLOh6a8m9gxWHw0L7S2KqPGqyx/PXHBn6QTbqm5n8TOmldgq+zusU SBAg== X-Gm-Message-State: AOAM5318Af0eryDL1CTZj4sNjI4i2ZnXqVw1RDNl8NLneO0Mxw6YdSAM gMRcDe6vzThiAxK8wj+F899NCvt2m87LblBUjmJbsrfixnSFhGmZ7sgxR8p31AGzbWwyLiHxa20 0yJmmubiqsA24+czkl5qEMDJL X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048464oih.67.1603816993830; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Cc: 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, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBB76C388F9 for ; Tue, 27 Oct 2020 16:44:23 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8621121707 for ; Tue, 27 Oct 2020 16:44:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="TpvGz5q1"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FbJgonJ1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8621121707 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id BA199167E; Tue, 27 Oct 2020 17:43:28 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz BA199167E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1603817058; bh=OQOHVS8bcGZvkTBJmwKxlEuTZIWdxWntvNhv0TMn9AQ=; h=From:To:Subject:Date:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=TpvGz5q1yx5ZeFrpIg1ok6P2bxj4Y3wUfep4KTTwvOp7r2HhBB3KwJz0NML91PTMd 7I1cw7DX8/3sMqZi0mNxMrShDeb8n270gOOIOhP7qvHWuGL9S1FHcOb3v+Ewd6wf/5 J9JL6Sksq3tjBH7ooXd+81fqsJFDVaUCBtUBRBic= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 11AFFF801D8; Tue, 27 Oct 2020 17:43:28 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 3F6FEF8020D; Tue, 27 Oct 2020 17:43:26 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6A3ABF800FF for ; Tue, 27 Oct 2020 17:43:21 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6A3ABF800FF Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FbJgonJ1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603817000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=FbJgonJ171jSzvgL5bSjkunUgVE0c/JRuU5j7wHHrOq44T6Rc1XG2YIppSgfyNdgm3+H4+ ctgWgWSzC+v9k4HbynT7FMiok41p91k/1D9XSsa58LSES6Nnoq9aGdn6qgLfcJgVN5pG0T MbesBu30ocjhHLF8C5sYgz0ikBjQ+6w= Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-35-NLrcfGp1PICkKHs6CRK8zg-1; Tue, 27 Oct 2020 12:43:15 -0400 X-MC-Unique: NLrcfGp1PICkKHs6CRK8zg-1 Received: by mail-oo1-f69.google.com with SMTP id w3so1026653oov.6 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=aFVxFvc3rmQUUxLnQGrBv+1lqJDWzIfVJx+ymEPELeaRf/8ovmTTudftL0zbXpgGLp MoHlVZ6i9Z9FdKDtQzK8Lgn4UZdcHBf2J0p3KXtn3Ey4PDJsK2woAKoHfS14pw2ZPjD9 6B/oVFcQSPNdyAmgSK8dZg7uWK17TCax7pKlK2B6mZQHIyXE98FOyF4iVketGFJHkv31 1MN0VDg9nUYddbZWzJEB3abYUwRZszanawImteXjQk6ZK9W7iHuajTUNFwK9iA4CXHgs 7N2UJ37+x2Av1Z2BaRdK8IQNBbHLCGa6W6/fq53DIUhIhL4qO8dnWOy8fUg0RPMww3Xv 4scA== X-Gm-Message-State: AOAM531jzR62Bh4wyn0B4CrIx0PXpKn+bIbpaA1QpXJPjlHOBQqTV2A0 OWMUPn7lscRY/j3UqkvVTGVs6NXnGutu+sa3RaHml8EGR1+MTFC86ZgqaznoTZP1vp/JAc+AvE5 MLAYTLlPXQYs/kBErubSXPWM= X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048484oih.67.1603816994021; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= , dri-devel@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72CC5C61DD8 for ; Tue, 27 Oct 2020 16:43:30 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0772820727 for ; Tue, 27 Oct 2020 16:43:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="D/3eFz34"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="T3JJPM73" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0772820727 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=MTTmIGafw1XvhPRdbDrvDwOKvj0DIrvrIp7esES39sg=; b=D/3eFz34XITJpq4lyD/AXySM51 MiMakGA0s4+OCPWELcnXw3HueDcjM62M/tdn6hSBpwJXjKUC/yRgxaIqIEvr4s03H2qBETQvY1qbg cytyMZ8pNOFed8fRqGrldc0RsIASRaABjKjm9Gf9g7IgXDTLhqSYIoUyDRiWIJzC7smyjj/SeW5gd V9WFLM/arZeJDKFad32EE/1E2uOxKZpKmmER1LwyodwvHYTurOAsm21OXz7/A9kuOW7FszOkxsFgX MPSWAuu2GSpzvE7kAubJQoYMGxq9aPT38Z1JJaZhPQxI+5xLsI5w8IZCtKnBOUmASI+NI1WPmUL6y gFcQQ1YA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXS49-0005K7-PS; Tue, 27 Oct 2020 16:43:21 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXS46-0005Ii-Rs for linux-mediatek@lists.infradead.org; Tue, 27 Oct 2020 16:43:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603816997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=T3JJPM73TuDKX/hT7gH/aQUzAU2d8gL+25TBFb+iUvjdY+xNCldEuR1hHDMz/2ymKmtcAH DJwGqFZUYpJHzmLUM+dgrSRfydn0AZKjiMU7whOx1X/eASiqj5JfKx18iSkqF/l+XVvkxt h9Wxzw5orBnfXpvZSnp3eRj1sGX+jwA= Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-220-FK80VZlANVWpDBCuwKdIHw-1; Tue, 27 Oct 2020 12:43:14 -0400 X-MC-Unique: FK80VZlANVWpDBCuwKdIHw-1 Received: by mail-oi1-f198.google.com with SMTP id w126so935828oif.16 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=o4la0M1XoySY+Fdopg9g32qsmd8v7OJCKqoFPJcPwPgWxgDuSWvTN1xIZ0ZFpEFT7/ 0weLsz3R7zlnc+esww8VrfFeHxQyB7IwqX2GPeXGgDPCiodXjktefC04Q/5ay5fxODPf yUNzBbmEzCD2FBL7Q2xUeUIOvOwQfJEJiDy7/RPBfjPl8YQdp/bIRwlJvB8/56d9Z35A iFitQjrK9N2aLi2ZlJyIDIZOA7gfG/RC6g2DyDtsMnLipRNStUNl0wNyN0MT2E1vTInQ vU1gUu4471MsONub/LAMzB+Nojj5MHkOHBZ4Eqjbn9Th/OvPnXukWT86yXNm3amavKhW a1Ng== X-Gm-Message-State: AOAM533vqB6P8mAkoBeBB+pexU7Yqqz5YcFXF07JwBALwiQ9zXYQ7wob mnRoBAZvRcdoExniQLIyyyd6yKfdcArrAUk5R+N5nl2dmBz4k5IPyYCpbbbbZz32YvjyD2RMe74 U0RgLAYY30aaqcnLugFqmNBYh/4iogD+S X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048454oih.67.1603816993826; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201027_124319_020036_6C1E4E49 X-CRM114-Status: GOOD ( 13.80 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= , dri-devel@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 249F6C55178 for ; Tue, 27 Oct 2020 16:43:25 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BB61420727 for ; Tue, 27 Oct 2020 16:43:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FbJgonJ1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB61420727 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CEC106E1D6; Tue, 27 Oct 2020 16:43:23 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id A44B76E1D2 for ; Tue, 27 Oct 2020 16:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603817000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=FbJgonJ171jSzvgL5bSjkunUgVE0c/JRuU5j7wHHrOq44T6Rc1XG2YIppSgfyNdgm3+H4+ ctgWgWSzC+v9k4HbynT7FMiok41p91k/1D9XSsa58LSES6Nnoq9aGdn6qgLfcJgVN5pG0T MbesBu30ocjhHLF8C5sYgz0ikBjQ+6w= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-422-ApWZ3ED_OFSjyJTvFFIa5Q-1; Tue, 27 Oct 2020 12:43:14 -0400 X-MC-Unique: ApWZ3ED_OFSjyJTvFFIa5Q-1 Received: by mail-oo1-f70.google.com with SMTP id q9so1036946ool.1 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=lhBApo4HfTGMxMttcT49asOswwshHHzXqcrE9HDp4dqsdr/Fhsxb3R3Ofkj8qtKo8G 88BcjU2oeVrLLyVnqEVWCKJeE9k+DMxu1g6Ssi7Ku6zBOpBnZbeR1wh08Si7KC9NQ2/f TzTl9jK6lmKYVHURU01/SwLPYc6H+ZQRgIPkyc3Irw6Hm9HOOH8Rh9K9eowAaso6W6gF Y4os7dQlJEq1TQ1OPwLkJCAnhYEtxHZSfjgASXonQWDfTdD9X9/698jvMOZWwRjEdt+d cgcCJQZv1CxZn3pa5vkRYe86gREF49xIx19VSYyhFMcjAt9hB7Z7GGkt5jMGO7G08nyf vPsQ== X-Gm-Message-State: AOAM532EbN3dBTINpXNLe0PmQitdTFvrn96Y0E7ecvCXZS/DW8t6D6RO jHsX2fJxaiNXYuuvsXhXjpmivma5/PVmebdBawbUxanCHN97ivoqO9pOYiJJxRZDYHVx+BgrZjL Kh4CGIfxp3Q8yI3aVwupo6kxS0VOw X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048467oih.67.1603816993830; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= , dri-devel@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6CEAC4363A for ; Tue, 27 Oct 2020 17:29:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 764D320657 for ; Tue, 27 Oct 2020 17:29:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RANYlVqx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 764D320657 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D7FB16E0D9; Tue, 27 Oct 2020 17:29:33 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id A9F816E1D2 for ; Tue, 27 Oct 2020 16:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603817002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=RANYlVqx9u8/qLxZJ/Ck6e2L6u++xD3Mm4AcnpwFnVJNQlHuRCYYD6+ElGHjGPSOAi1PU9 uDuwWFM0SzZ+0RhiNpFKgvpQmpUwc7845JMTiSXwwOR1l7LjUK1FPHWNuKpV1PrrThRsTo uwebzizDBSmcPDDR41r8W8XhNJzl9zU= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-158-MKwocxfWOQqtWtmglF426w-1; Tue, 27 Oct 2020 12:43:14 -0400 X-MC-Unique: MKwocxfWOQqtWtmglF426w-1 Received: by mail-oi1-f199.google.com with SMTP id 65so942426oii.10 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=AbvvEfXnH/ahFEBlEdhgA6gLdl8Y9GJBNPoJZFzOR+m8RTT3Rky4I1Xu3PpBCaFuE+ PQUJwycpFZ64NxqvJ86BndrMzPkIHM5M9bghGeEpFH4N0g9UUIhgDxkv+IN2/R+PPoRV Rm5PL/YoxiK629udjzsU587qvT9lQ5yghD7mqrk/ruOg2SCJHDc29n2Pf+ot5qgII1G1 ASAclMJ8/ZSOigxy+PO/ljndkBH0XenQY1wywcXQ1lmjBRLYZF4unrmajZq9gg5HIDdL RJpsBm9tJC6oNE55/OXmhfH4QAWI9QqInrWAhwuadDGtaLrhUr/kaF2+mEih8npBECMz 1SrQ== X-Gm-Message-State: AOAM5312TXa9XdrR6GYPZHUBJeVBMW22ZpyC1wlyI1pl3ij7FfOGRCfX 4IWby/R46LHgtIPJMxM95x685/yTLznCxAcoE8Uv8nxzwoYwYRTwMZYizZtjAobGlXvAhki9sTz CCB21X+Ei85PoBhkClFQLQwdVrQ== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048450oih.67.1603816993826; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Mailman-Approved-At: Tue, 27 Oct 2020 17:29:33 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= , dri-devel@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB413C55179 for ; Tue, 27 Oct 2020 16:43:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5973421D7B for ; Tue, 27 Oct 2020 16:43:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N42mGx68"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Rm8lFjcL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5973421D7B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=2xJSf55PdWlcscfM25Iy1EPthXHa2dWdo5p7OHyPT0s=; b=N42mGx68ydvDTYDyACPxWpoHZI Bkbi6pNuioXtBV1mLHYpDimO3GNctZCYP04olEnM0NCp81eOx5nhumf6oBtjh3PO3ztsxX9HADeUs uw7DthDlAL2BaE0B1Srggg7ai1MHUOrsTliZVVTJUVwSAdzb7MyH/wITLtTF+RDDIF5OrBhxNigjp VPs7vwOFeG5ch5ndzC2WQNdJCRkfc2dDKSQUt10MlnBCYwWkLvuZMRtEPR9MnPU7hcm1+UXhnpCrk EEK5usVmab/y8CBrBuxSqEJi5JYcrDGVFYR4DeT40O0eaETsriCSD9jqeHWFCrDUYILEn5gjzUPSH C+5+fOuQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXS4A-0005KY-Sm; Tue, 27 Oct 2020 16:43:22 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXS46-0005Il-TL for linux-amlogic@lists.infradead.org; Tue, 27 Oct 2020 16:43:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603816998; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=Rm8lFjcLDGjqVK+tlzRsk5hVuzRKiz1PAzcIS7c2opzFTvN054de1Vj2dlRfrKKYMGkiBm gtoa0Aj2GP7OJ6D4b+nmSO+jFhDRdmS+Wyw7zDhfnjSzQvRZVwEVtbYOoWuvhD4RJ0zjvP C3ByGepOLdQ9UpNgeNinjXpi+99jaxI= Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-bJptS_faNP6AizjZuD6z6w-1; Tue, 27 Oct 2020 12:43:14 -0400 X-MC-Unique: bJptS_faNP6AizjZuD6z6w-1 Received: by mail-oo1-f69.google.com with SMTP id j5so1030551ooq.4 for ; Tue, 27 Oct 2020 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=mj6uaiHROCag3uZJ/gHJroorYDnXKuN4EyYRFIYPu8Y=; b=LViMGFmhRG+f4hyHBTXc0EM8KvPnLErm5/Zr0zkuGUMEiDdwbMDEI8PmyuIjQ+1dlb FclYsT6dzFS0zIJX7pMDv+Ov1tQ6/zhicptLWHe+xZKrRNsTqW5WNrVtOiCyqPG5+JhQ AtU3peXph0A4LNPSIrRfyWZ4EFyLdTIruN+sSyqCmAco2CkMEsISczB/JdIn5gO6xenx 5+2XoCKwtRqm1A9FncOwKXjKBLaYoKh6g2oaxoE6DdWOiDgqbSFfCdqq9sgz7A/ofOoc ivjYBowrPBm63Xj1pZK3IvD5mP3V6K3BRVBPHE/1LCgTP5hh7PnZqmWj0Rvsk42DbCN9 YvyQ== X-Gm-Message-State: AOAM530HtZP/KH/cYRUmf1NKFmTlReTcRZJW0knOEA3sSGgTr9TP5tJC vrWAS5xmmYRQ6dfRVWwm/ixsfZjoxEGjD+mhY1C94GG8+Vgjas9J+H4qOZyQeSWNb97x6WWFMxP mMylggpMiy+p4ue/eJuoKJrL+rcpA9rM= X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048457oih.67.1603816993827; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7y1eCX7WfRNi9tkZnfLpiDio1qtG9FKTpwYlLMD9SlPYp6FIE57BquNUx5oTk2cs+UUc+WA== X-Received: by 2002:aca:ef03:: with SMTP id n3mr2048435oih.67.1603816993577; Tue, 27 Oct 2020 09:43:13 -0700 (PDT) Received: from trix.remote.csb (075-142-250-213.res.spectrum.com. [75.142.250.213]) by smtp.gmail.com with ESMTPSA id l89sm90968otc.6.2020.10.27.09.43.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2020 09:43:12 -0700 (PDT) From: trix@redhat.com To: linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Subject: [RFC] clang tooling cleanups Date: Tue, 27 Oct 2020 09:42:55 -0700 Message-Id: <20201027164255.1573301-1-trix@redhat.com> X-Mailer: git-send-email 2.18.1 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201027_124319_062825_4CAA9898 X-CRM114-Status: GOOD ( 13.80 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, =?UTF-8?q?=EF=BB=BFFrom=20=3A=20Tom=20Rix?= , dri-devel@lists.freedesktop.org, linux-stm32@st-md-mailman.stormreply.com, linux-rtc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org, qat-linux@intel.com, amd-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-mmc@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org 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. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks safe to fix all the time. An example problem void foo(int a) { switch(a) { case 1: ... }; <--- extra semicolon } Treewide, there are about 100 problems in 50 files for x86_64 allyesconfig. These fixes will be the upcoming cleanup. clang already supports fixing this problem. Add to your command line clang -c -Wextra-semi-stmt -Xclang -fixit foo.c foo.c:8:3: warning: empty expression statement has no effect; remove unnecessary ';' to silence this warning [-Wextra-semi-stmt] }; ^ foo.c:8:3: note: FIX-IT applied suggested code changes 1 warning generated. The big problem is using this treewide is it will fix all 10k problems. 10k changes to analyze and upstream is not practical. Another problem is the generic fixer only removes the semicolon. So empty lines with some tabs need to be manually cleaned. What is needed is a more precise fixer. Enter clang-tidy. https://clang.llvm.org/extra/clang-tidy/ Already part of the static checker infrastructure, invoke on the clang build with make clang-tidy It is only a matter of coding up a specific checker for the cleanup. Upstream this is review is happening here https://reviews.llvm.org/D90180 The development of a checker/fixer is Start with a reproducer void foo (int a) { switch (a) {}; } Generate the abstract syntax tree (AST) clang -Xclang -ast-dump foo.c `-FunctionDecl |-ParmVarDecl `-CompoundStmt |-SwitchStmt | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt Write a matcher to get you most of the way void SwitchSemiCheck::registerMatchers(MatchFinder *Finder) { Finder->addMatcher( compoundStmt(has(switchStmt().bind("switch"))).bind("comp"), this); } The 'bind' method is important, it allows a string to be associated with a node in the AST. In this case these are `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp |-SwitchStmt <-------- switch | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt When a match is made the 'check' method will be called. void SwitchSemiCheck::check(const MatchFinder::MatchResult &Result) { auto *C = Result.Nodes.getNodeAs("comp"); auto *S = Result.Nodes.getNodeAs("switch"); This is where the string in the bind calls are changed to nodes `-FunctionDecl |-ParmVarDecl `-CompoundStmt <-------- comp, C |-SwitchStmt <-------- switch, S | |-ImplicitCastExpr | | `-DeclRefExpr | `-CompoundStmt `-NullStmt <---------- looking for N And then more logic to find the NullStmt auto Current = C->body_begin(); auto Next = Current; Next++; while (Next != C->body_end()) { if (*Current == S) { if (const auto *N = dyn_cast(*Next)) { When it is found, a warning is printed and a FixItHint is proposed. auto H = FixItHint::CreateReplacement( SourceRange(S->getBody()->getEndLoc(), N->getSemiLoc()), "}"); diag(N->getSemiLoc(), "unneeded semicolon") << H; This fixit replaces from the end of switch to the semicolon with a '}'. Because the end of the switch is '}' this has the effect of removing all the whitespace as well as the semicolon. Because of the checker's placement in clang-tidy existing linuxkernel checkers, all that was needed to fix the tree was to add a '-fix'to the build's clang-tidy call. I am looking for opinions on what we want to do specifically with cleanups and generally about other source-to-source programmatic changes to the code base. For cleanups, I think we need a new toplevel target clang-tidy-fix And an explicit list of fixers that have a very high (100%?) fix rate. Ideally a bot should make the changes, but a bot could also nag folks. Is there interest in a bot making the changes? Does one already exist? The general source-to-source is a bit blue sky. Ex/ could automagicly refactor api, outline similar cut-n-pasted functions etc. Anything on someone's wishlist you want to try out ? Signed-off-by: Tom Rix _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic