[llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 1 10:13:36 PDT 2020


On Wed, Jul 1, 2020 at 3:46 AM MyDeveloper Day via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> @Timothy Keith,
>
> Through this I've become aware of several sub-projects/libs that are either 100% clean or near 100% clean (flang,milr)
>
> I have my own internal 5 million line code base which is 100% clang-formatted (including all C# and JS, unit tests), plus Firefox is also I think 100% converted, some helpful devs over there pull some patches and check for regressions if I add them as reviewers.
>
> I always knew "polly" was mostly clean too, and actually one of the areas I already test against, (along with lib/Format obviously).
>
> If we could get whole sub-projects 100% clean then it would be possible for me to notify them downstream when a clang-format change (for a bug fix) requires an update. But without that 100% status I'm always playing a game of checking every change, once we are at sub-project at 100% any change in formatting can be identified as a potential bug.
>
> The current process I'm building is for the script that generates that html page to also generate a list of directories that are 100% clean, then use that as input to a test which validates clang-format, any clang-format replacements signify either recent unformatted changes or potentially bug fixes or regressions. (all of which in my view are worth highlighting to either clang-format or the owners of the subprojects)
>
> Where sub teams can help is by making their projects 100% clean and helping to enforce/maintain that. We really try to not change LLVM default style but I am trying to work my way through the bugs and that from time to time does show differences. ideally I would run this regression on your sub-projects and then @mention your Phabricator project that inside review. (or send a review of the changes)
>
> This is not about imposing style on anyone, It is purely about ensuring we don't break the world as fixing bugs inevitably causes some instability.  However one wrong move could have massive ripples through all the projects that use clang-format, the unit tests are excellent but regressions still slip through the net, and we already had a case where v10 had an issue which impacted others after it had been branched. I feel we need to ensure clang-format is run over millions of lines of code to catch bugs as early as possible. (and to root out new ones), it will be of huge benefit to clang-format if our own code base is heavily formatted so I really appreciate those who consider this worthwhile.

I'm still curious/confused why this requires (or significantly
benefits from) actual 3rd party code to be clang-formatted in the
projects (LLVM and otherwise) themselves. Compared to clang-formatting
such a codebase on a branch (possibly even a local branch) with an old
clang-format and a new one, and checking any deltas are desirable?

- Dave

>
> MyDeveloperDay
>
>
> On Wed, Jul 1, 2020 at 12:54 AM Timothy Keith <tkeith at nvidia.com> wrote:
>>
>> The flang sub-project is supposed to be fully formatted so it wouldn’t be hard to get to 100% for a test like this and we would be happy to participate. We were at 100% at one point but there are about 10 files that need formatting now, in part because of changes to clang-format. It would be good to get early warning of clang-format changes like that.
>>
>>
>>
>> Let me know if there is anything I can do to help.
>>
>>
>>
>> Tim
>>
>>
>>
>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
>>
>> On Jun 28, 2020, at 8:30 AM, MyDeveloper Day via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>>
>>
>> (Copying from Discourse)
>>
>> All
>>
>> A couple of months ago I added the following page documentation Clang-Formatted-Status to track the status of “How Much” clang-formatted the
>>
>> LLVM/Clang project is.
>>
>> Wow, I hadn’t seen this - this is really cool!
>>
>>
>>
>> I’m a contributor to clang-format and would like to see LLVM 100% clang formatted so we can use LLVM as a massive test-suite for clang-format when we make changes.
>>
>> In the last couple of months since we added this page the % has gone up by ~4% and this is likely in most part of either: a mention in LLVM-Weekly, the premerge checks or perhaps some recent clang-format efforts by individuals. This is fantastic and every directory that gets to 100% increase the directories that I can run against to check against.
>>
>> I’m a huge fan of clang-format, and have worked in “required to be formatted” code bases - it is a way better way to work in my opinion.  That said, such a move that you’re talking about is something that will take time, because this is a social problem as well as a technical one.
>>
>>
>>
>> Instead of starting from a “can we do everything” question (which you’re already getting some “no’s”), I’d start with an easier question of “is anyone ok with mechanically formatting any pieces of llvm?”  There will be some folks (e.g. the MLIR ones, perhaps the flang ones?) that are more likely to be early adopters, and this gives the opportunity to figure out policies and tools to help maintain things.  Then you can move on to other subdirectories within llvm/clang/etc, and progressively get there.
>>
>>
>>
>> This helps achieve your goal of getting more of the stack, but avoids it being an “all or nothing” sort of dichotomy.
>>
>>
>>
>> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list