[flang-dev] Code formatting alignment with LLVM

[David Truby via flang-dev]

HI Johannes, sorry for the delayed reply.

The regex that is already there sort of “accidentally” works for clang as c is higher up in the alphabet than any other LLVM subproject.
The coding guidelines say that the sorting of header includes should be in the order of most specific to least specific LLVM subproject.
This is very likely going to be different for each individual subproject, so I think this is one case where divergence from the main LLVM style is easy to argue aligns us better with the actual intended coding guidelines.
For example, in our case we want the order flang -> fir -> MLIR -> clang -> LLVM, but this isn’t the order that e.g. libc++ would want. I don’t think this difference is captureable in the global style.

Thanks
David Truby

On 11 Feb 2020, at 17:31, Doerfert, Johannes <jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>> wrote:

On 02/11, David Truby wrote:
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!

It does, thank you.

Can we add flang to the regexp and thereby avoid the actual
configuration in the .clang-format? I mean, flang is an llvm subproject
as clang is, why treat it differently?

---
ag 'llvm\|llvm-c\|clang\|clang-c' clang/

clang/docs/ClangFormatStyleOptions.rst
1584:      - Regex:           '^"(llvm|llvm-c|clang|clang-c)/'

clang/include/clang/Tooling/Inclusions/IncludeStyle.h
98:  ///     - Regex:           '^"(llvm|llvm-c|clang|clang-c)/'

clang/lib/Format/Format.cpp
792:      {"^\"(llvm|llvm-c|clang|clang-c)/", 2, 0},

---


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

--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov<mailto:jdoerfert at anl.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200213/6fb79e4c/attachment-0001.html>