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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 47A65C55178 for ; Tue, 27 Oct 2020 21:09:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CED462075E for ; Tue, 27 Oct 2020 21:09:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G3Jcho8Q" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S373536AbgJ0VJj (ORCPT ); Tue, 27 Oct 2020 17:09:39 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20922 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2505267AbgJ0VJj (ORCPT ); Tue, 27 Oct 2020 17:09:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603832977; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qVwaS8BTcuMOMUfHEzFFtE2wVD4D7uQ2zVsYJoC6aXQ=; b=G3Jcho8Q4OcwBKC+xjoRevK0KiVmWvAAC+/0m0NnG3ySkkDqHdyPlv3tu8RY2yEk3GqnzV haPuuzyL5ctayXZLvH0cW4/DOBxL/T3jFTH6Np3GK9gkhW3ZHfnXUJidI8U+9OwL/i7gV1 8ZsfZXjGTJwj5l/Xis8as4v5wWlhwt4= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-427-9J0IrQfwNuWd7Is6hw2URg-1; Tue, 27 Oct 2020 17:09:35 -0400 X-MC-Unique: 9J0IrQfwNuWd7Is6hw2URg-1 Received: by mail-ot1-f72.google.com with SMTP id y26so900712otk.4 for ; Tue, 27 Oct 2020 14:09:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=qVwaS8BTcuMOMUfHEzFFtE2wVD4D7uQ2zVsYJoC6aXQ=; b=BT2NPtdHwmSB0Yp3l9VX/qlgjOzTekHbHpH6XFqkoY0B0xp2m/JRZpQo/w+JwY86/K ixHjRvfplQ+lJJpmIhxLMYED2yvSuCml5B3v25XYoTUZa5RosY46ORupzGzw+ItjeAN5 xoyxog+d92Iq/H1i59ZEJn0qzUrm9qca7Qkm7wDkMmsAOi7KQ5ettnqM1TFxje1yYpjz k1mIJHYBCxhIcf9Pw5vNJj3YqTLE8wdoHJ5Cp41Gbw490WNcWqGmlcP8X/s7QfoKDa6q sp3S8pG+p3VrEe7Tw/s7No3Fd36b4L6i1PeWmqQkRfrDF39HAggSahCkvKAn2ZiN9SVT 8Yqg== X-Gm-Message-State: AOAM532+FFUrNCXWJ0sVt6jn4/LxRqlVFF4wGWXvxpplPZQqIHtj5RaV bbm9gszcmADd3GuD+AiId4hLthutWMh5BTpSk/7xn9YfaDLFOYHnrD1Pj6TyUb8HSuIM3KFAxph ZtuNsUnADNGlAvYfTILbfwuEWK01g5Q== X-Received: by 2002:a4a:7c85:: with SMTP id v127mr3275896ooc.29.1603832974723; Tue, 27 Oct 2020 14:09:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysAfRp8j/ZP5YN2JfWvZmU9l8uTXc/Khi6vIE4elxS3sJoxjDY6Vw4q+4qjoeiuLSmPHXvHw== X-Received: by 2002:a4a:7c85:: with SMTP id v127mr3275883ooc.29.1603832974485; Tue, 27 Oct 2020 14:09:34 -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 l11sm1553497oon.35.2020.10.27.14.09.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 14:09:33 -0700 (PDT) Subject: Re: Subject: [RFC] clang tooling cleanups To: Joe Perches , Nick Desaulniers , Stephen Rothwell Cc: LKML , clang-built-linux , linux-toolchains@vger.kernel.org, Julia.Lawall@lip6.fr, Linus Torvalds , Masahiro Yamada , Nathan Huckleberry References: <20201027164255.1573301-1-trix@redhat.com> <8abd1e5a-511a-e4f6-6f2c-a045d33fa2aa@redhat.com> From: Tom Rix Message-ID: Date: Tue, 27 Oct 2020 14:09:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: 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=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On 10/27/20 12:51 PM, Joe Perches wrote: > (Adding Stephen Rothwell) > > On Tue, 2020-10-27 at 12:33 -0700, Tom Rix wrote: >> On 10/27/20 11:42 AM, Nick Desaulniers wrote: >>> (cutting down the CC list to something more intimate) > [] > >> I am interested in treewide fixes. > As am I, but here the definition of fixes is undefined though. > Whitespace / style changes and other bits that don't change generated > object code aren't considered fixes by many maintainers. > >> Cleaning them up (maybe me not doing all the patches) and keeping them clean. >> >> The clang -Wextra-semi-stmt -fixit will fix all 10,000 problems > I rather doubt there are 10K extra semicolons in the kernel source tree. > Is there a proposed diff/patch posted somewhere? Not as-such, the number comes from adding -Wextra-semi-stmt to a clang allyesconfig. grepping and sorting unique warnings. I did a similar over view for no newlines at end of file and unneeded breaks which turned up 2 and ~250 problems. > >> This clang tidy fixer will fix only the 100 problems that are 'switch() {};' >> >> When doing a treewide cleanup, batching a bunch of fixes that are the same problem and fix >> is much easier on everyone to review and more likely to be accepted. > That depends on the definition of batching. > > If individual patches are sent to multiple maintainers, the > acceptance / apply rate seems always < 50% and some are rejected > outright by various maintainers as "unnecessary churn". > > Single treewide patches are generally not applied unless by Linus. > The trivial tree isn't widely used for this. > > Perhaps a 'scripted' git tree could be established that is integrated > into -next that would allow these automated patches to be better > vetted and increase the acceptance rate of these automated patches. > >> Long term, a c/i system would keep the tree clean by running the switch-semi checker/fixer. >> And we can all move onto the next problem. > Good idea... > I hope a scripted patches mechanism will be established. I would be interested in this as well. I already have a repo tracking next. I can code up a script to do the commits. Then we can poke at it with sticks and see if hooking it into next is worthwhile. Tom > >