[flang-dev] Code formatting alignment with LLVM

Thu Feb 13 15:54:59 PST 2020

The comments, I missed that somehow.

TBH, most of the code I see (in LLVM), and all the code I write, doesn't
have trailing comments to begin with. That would be my preferred
solution to this particular problem(, not all alignment issues though).

On 02/13, David Truby wrote:
> Hi Tim,
> 
> We are currently under a different level of scrutiny to existing established and successful LLVM projects, and one need only look at this week's llgo removal to see why the community is more concerned about adding new frontends than it may previously have been.
> I would personally suggest that if other LLVM projects have disalignment from the overall LLVM style here and it is undocumented why then that is a defect that we should raise diffs on Phabricator for those too. However I think that it's separate from and orthogonal to the discussion we are having about flang.
> 
> With regards to Phabricator it is unfortunate that it doesn't show these diffs in a better way. Is it possible to configure it to do so?
> 
> Thanks
> David Truby
> ________________________________
> From: Timothy Keith <tkeith at nvidia.com>
> Sent: 13 February 2020 23:29
> To: David Truby <David.Truby at arm.com>; Johannes Doerfert <jdoerfert at anl.gov>
> Cc: David Truby via flang-dev <flang-dev at lists.llvm.org>
> Subject: Re: [flang-dev] Code formatting alignment with LLVM
> 
> 
> If AlignTrailingComments had been set to false in .clang-format, lines 321 and 322 would not have changed and so Phabricator would not show them as having changed. It’s no better than in the github PR.
> 
> 
> 
> I notice that openmp/runtime/.clang-format also uses “AlignTrailingComments: false”.
> 
> 
> 
> Tim
> 
> 
> 
> From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of David Truby via flang-dev <flang-dev at lists.llvm.org>
> Reply-To: David Truby <David.Truby at arm.com>
> Date: Thursday, February 13, 2020 at 1:35 PM
> To: Johannes Doerfert <jdoerfert at anl.gov>
> Cc: David Truby via flang-dev <flang-dev at lists.llvm.org>
> Subject: Re: [flang-dev] Code formatting alignment with LLVM
> 
> 
> 
> External email: Use caution opening links or attachments
> 
> 
> 
> Hi Johannes,
> 
> I didn't realise we could upload the same diff on Phabricator to look at, that's really helpful!
> 
> 
> 
> I believe we are looking at lines 320-324 of PFTBuilder.h.
> 
> I don't see a real significant difference in the way this is displayed I suppose. Phabricator doesn't pick up that lines 323 and 324 on the right are the same as 312, 322 on the left sans formatting.
> 
> However, I think that even if the formatting was the same Phabricator would display this in the same way as that's just how it displays diffs?
> 
> 
> 
> Maybe Tim can comment on what he thinks of this?
> 
> 
> 
> Thanks
> 
> David Truby
> 
> 
> 
> 
> 
> ________________________________
> 
> From: Johannes Doerfert
> Sent: Thursday, 13 February 2020 21:27
> To: David Truby
> Cc: David Truby via flang-dev
> Subject: Re: [flang-dev] Code formatting alignment with LLVM
> 
> 
> 
> On 02/13, David Truby via flang-dev wrote:
> > Hi all,
> >
> > Tim Kieth from Nvidia has provided a specific example from the recent
> > FIR pull request where the indentation rules caused spurious diffs
> > (see this comment:
> > https://github.com/flang-compiler/f18/pull/945#issuecomment-585856610).
> >
> > I'm curious if this is also something that shows up badly in
> > Phabricator or if that has a better way of showing diffs involving
> > whitespace. Is anyone familiar enough with Phabricator to comment on
> > this? I wonder if Phabricator might just be better at handling code
> > reviews of this ilk better, meaning that this problem is less visible
> > to clang/llvm developers.
> >
> 
> Here is the diff:
> https://reviews.llvm.org/differential/diff/244525/
> 
> What line numbers are we looking at again?
> 
> 
> > Thanks
> > David Truby
> >
> > ________________________________
> > From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of David Truby via flang-dev <flang-dev at lists.llvm.org>
> > Sent: 11 February 2020 10:20
> > To: flang-dev at lists.llvm.org <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
> 
> > _______________________________________________
> > 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
> 
> ________________________________
> 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.
> ________________________________

-- 

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/394b23bc/attachment-0001.sig>