[flang-dev] Code formatting alignment with LLVM

Thu Feb 13 13:18:40 PST 2020

On 02/13, Eric Schweitz (PGI) via flang-dev wrote:
> Hi David,
> 
> Thanks for the reply.
> 
> There was some discussion about refactoring some of the driver code
> into “common” bits and C/C++ “specific” bits. I don’t know which
> direction that went off in. Maybe someone else knows.
> 
> But it could also be true that such a refactoring happens entirely
> within the existing clang directory structure. It’s not clear if that
> wouldn’t be a bit confusing in a compassionate coding sense, more so
> than finding a “generic shared driver parts” home.

The argument was made that we should split generic driver code off and
put it into `llvm/lib/Frontend/Driver`.

> --
> Eric
> 
> From: David Truby <David.Truby at arm.com>
> Sent: Thursday, February 13, 2020 2:26 AM
> To: Eric Schweitz (PGI) <eric.schweitz at pgroup.com>
> Cc: flang-dev at lists.llvm.org
> Subject: Re: Code formatting alignment with LLVM
> 
> Hi Eric,
> 
> I believe there will be in the Driver, as that will be sharing some of clang’s driver code. Perhaps someone else can give a better answer on this than me though?
> 
> David
> 
> 
> On 11 Feb 2020, at 18:55, Eric Schweitz (PGI) <eric.schweitz at pgroup.com<mailto:eric.schweitz at pgroup.com>> wrote:
> 
> Are there cases where flang and clang headers are both used in the same module?
> 
> From: flang-dev <flang-dev-bounces at lists.llvm.org<mailto:flang-dev-bounces at lists.llvm.org>> On Behalf Of David Truby via flang-dev
> Sent: Tuesday, February 11, 2020 9:22 AM
> To: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>; flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>
> Subject: Re: [flang-dev] Code formatting alignment with LLVM
> 
> Hi Johannes,
> 
> The header exception we are referring to is the IncludeCategories: section in the clang-format file. The default LLVM style has (llvm|llvm-c|clang|clang-c) as prefixes for headers to ensure those headers appear first when includes are sorted. This follows the Coding Style which says that LLVM sub-project includes should be sorted from most specific to least specific.
> 
> As a small example: if we don't add this specific excpetion and I write
> #include <flang/parser/parse-tree.h>
> #include <clang/Driver/Driver.h>
> this will be re-sorted to
> #include <clang/Driver/Driver.h>
> #include <flang/parser/parse-tree.h>
> as clang is higher in the priority order than flang without an additional exception.
> 
> Given that the order should be different for each sub-project (as their own headers should be first) I think this one addition to the clang-format file does make sense, rather than having it in the global style.
> 
> I hope that explanation helps!
> 
> Thanks
> David Truby
> 
> 
> ________________________________
> From: Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>>
> Sent: 11 February 2020 14:05
> To: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>; David Truby <David.Truby at arm.com<mailto:David.Truby at arm.com>>
> Subject: Re: Code formatting alignment with LLVM
> 
> I'm always in favor of minimizing the differences. It helps getting "accepted" by the community but also me personally. I'm used to llvm settings, anything that differs looks weird and will make my workflow uneasy. I think a lot is just conditioning, when I read diffs, for example, the color highlighting is usually good enough to show the non-alignment change even if things moved a bit. I don't notice that as a problem by now, which is not to say I don't understand the arguments made for the current f18 settings.
> Btw. I failed to find the clang format "clang header exception" mentioned in the call yesterday. Can someone show me a minimal example to show the effect? I mean, what does clang do differently for which we need an extra option? It sounds like something that needs fixing and we might be able to sign with llvm without changing the current options.
> Cheers,
>   Johannes
> 
> 
> P.s. I strongly advice to have discussions on the list or on phabricator, whichever is applicable. We already know various ppl do not monitor/interact with GH.
> --
> written from my phone
> 
> ________________________________
> From: flang-dev <flang-dev-bounces at lists.llvm.org<mailto:flang-dev-bounces at lists.llvm.org>> on behalf of David Truby via flang-dev <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
> Sent: Tuesday, February 11, 2020 4:20:57 AM
> To: flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org> <flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>>
> Subject: [flang-dev] Code formatting alignment with LLVM
> 
> Hi all,
> 
> We have been having a discussion on the GitHub issue tracker about code formatting (and specifically clang-format settings) and whether to align closer with the rest of the project, which you can find here: https://github.com/flang-compiler/f18/pull/945. Since the discussion there hasn’t moved much recently I’d like to start a discussion here so we can get input from a wider group of people.
> 
> My opinion is that regardless of technical preferences we shouldn’t diverge from the style of the rest of the project as much as we currently do, or at least if we want to do that then we should have a discussion with the wider community about whether that is acceptable to them.
> 
> Does anyone else have any input on this?
> 
> Thanks
> David Truby
> ________________________________
> This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
> 

> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200213/0c6d627a/attachment-0001.sig>