similar to: Codifying our Brace rules-

I'm with Matt on this one. I much prefer the approach of ALWAYS use braces for ifs and for loops, even if they're not needed, for basically the same reasons as he put. The number of times I've added a statement inside an if without braces and forget to add them is annoyingly high, especially as it's not always an obvious error upfront. Similarly, being involved in a downstream

On Mon, Jun 15, 2020 at 4:05 PM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As another data point, the MLIR part of the codebase is pretty consistent on this: never use braces for trivial (single statement) if/else/for, but always put it on every branch if needed on any side of the if/else. Any opinion/stance policy/practice on the "one line, or one statement

My 2 pennies is braces add unnecessary clutter and impair readability when used on a *single-line* statement. I count comments, that are on their own line as statement(s). For example: BAD: if (cond) // Comment foo(); GOOD: if (cond) { // Comment foo(); } BAD: if (cond) { foo(); // Comment } GOOD: if (cond) foo(); // Comment BAD: if (cond) for(;;) foo() GOOD: if (cond)

On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary

On 6/23/20 9:39 AM, Robinson, Paul via llvm-dev wrote: > >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jay Foad via >> llvm-dev >> Sent: Tuesday, June 23, 2020 4:47 AM >> To: Mehdi AMINI <joker.eph at gmail.com> >> Cc: llvm-dev at lists.llvm.org; Matt Arsenault <arsenm2 at gmail.com>

Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> writes: > I think braces should be added in all contexts, and the more contexts > the better. It eliminates any inconsistency or attempt to contextually > interpret rules. It also reduces merge conflicts, since something > eventually something will probably be added inside any control flow > statement. I’ve suffered

Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> writes: > For those who don’t like it, is the currently documented policy broken > enough to be important to changing? I believe it is, simply for safety reasons. Adding a statement to a single-statement block can introduce bugs. Mandating braces everywhere prevents that. > I assume you wouldn’t recommend a massive rewrite

Did this conversation reach a conclusion? My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. I didn't

At the very least, I accept clarifying the wording to make it clear where braces should/shouldn't be used. I personally would still prefer a general "always add braces in new code" rule, given that I literally just ran into another case where a code change I made locally caused test failures because I'd forgotten to add the braces on a previously single-line if, although in this

Personally, I favor "always use braces" because it helps readability for me. The compiler may be good at flagging misleading indentation, but my visual processing system is terrible at it, especially since we use a measly two spaces for indentation. And we grant indentation exceptions for--among other things--case labels in switches. When some nested statements have braces and others

I'll note that reading along I haven't found any of the proposed changes particularly worthwhile.  I'm also not strongly opposed to any of them - I just don't care - but I certainly haven't been convinced there's any clear benefit to be had by changing our current policy. Philip On 6/22/20 1:44 PM, Chris Lattner via llvm-dev wrote: > For those who don’t like it, is

Me? I would modify the first sentence from: > When writing the body of an if, else, or loop statement, > omit the braces to avoid unnecessary line noise. However, > braces should be used in cases where the omission of braces > harm the readability and maintainability of the code. To be: > Braces are optional around the body of an if, else, or loop statement, > except in cases

To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE. I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less

I mean, we could change it twice? There are about a hundred scripts out there for doing it. -eric On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote: > Do we have any ability to reach out to github (at least?) to see what they > are going to do? I’d very much like to avoid being the odd-project-out > here. > > > > > > > >

I disagree with your timing concerns. Changing is still straightforward and I'd like to see this done within 1-2 weeks. Thanks. -eric On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > +1 to waiting until git and/or github decide on a new name for the default > branch. I think there is a compelling reason to change the name of the > default

Sorry for the inline-comment format being weird, I haven't figured out yet how to do '>' stuff in outlook yet :/ Hopefully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re:

As I mentioned on another thread, we also use the term "slave" for the BuildBot builders. In the past, I was told this was due to being stuck on an old version of BuildBot. Fortunately, there is already work in progress to update BuildBot to a newer version. Since that's also going affect all the build machines, perhaps changing the name of the main branch should happen

That's a good point, we should definitely be respectful of the build bot owners time, that said I think it's the coordination that takes the time rather than the change :) On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding is the biggest concern about the name change is the > ‘cost’ associated with needing to

There's really no guarantee that things will shake out the same in near term between the projects. -eric On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote: > I’m a bit mixed on this. While yes, we should change this as soon as is > practical, it would be a shame to pick something sufficiently different > from the rest of the world, as that would

Alright, I guess it isn’t just my pain then, it makes it feel better ☺ I think that proposed feature would be really nice, since it would encourage people to write tests that have a //CHECK: some-thing-after-header first! From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, March 30, 2017 11:15 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: