search for: brace

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 register any technical arguments...

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 where the omission of brac...

...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 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 statem...

...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> >> Subject: Re: [llvm-dev] Codifying our Brace rules- >> >> 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 fi...

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 involv...

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 su...

...some time. > > -Chris > >> On Jun 22, 2020, at 1:36 PM, Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> 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'...

...escriptive" sounds self-contradictory. Are you in favor of talking about clarifying the existing guidelines or changing them to be less prescriptive? Or maybe you want to change them a little so that they are easier to express clearly? There are already several well-defined de facto standard brace styles. One way to make the guidelines clear (and concise) is simply to declare LLVM uses $(FOO) Brace Style with a link to the Wikipedia description. That suggests to me that it's not super feasible to divorce clarification from style choice, at least, not without putting a bound on how clea...

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 (c...

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...

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 swit...

Hi all- A few weeks ago I noticed that our "omit braces with single line blocks" rule wasn't written down! Additionally, as a group on IRC and in review, noticed that the enforcement of this rule has been extremely inconsistent. We made a first run at codifying our existing practice here: https://reviews.llvm.org/D80947, which was then commi...

Hi paulr: Thanks for your kindly response. Maybe I don't describe my question cleanly, let me show more information. From my side, I notice that whether we are in the continue keyword mode or we are in the right brace mode, the target of br instruction is the same, i.e. for loop Continue Keyword Mode: ; <label>:6: ; preds = %3 br label %7, !dbg !23 ; <label>:7: ; preds = %6 %8 = load i32, i32* %2, align 4, !dbg !25...

...r 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 of the codebase, so > we’re going to be with this for quite some time. Sure, that's unavoidable. But as code changes we can add braces where they're missing and reviews should catch cases where we forget...

...continue' statement, and one as part of the control flow of the 'for' loop. The branch for the 'continue' statement would have the source location of the 'continue' and the branch for the control-flow of the 'for' loop would have the source location of the right brace. Clang is smart enough that in the 'continue' example, it knows not to emit the second branch (it would be unreachable). --paulr From: Frozen [mailto:bluechristlove at 163.com] Sent: Saturday, June 03, 2017 8:13 AM To: Marcin Słowik Cc: llvm-dev at lists.llvm.org; Robinson, Paul Subject: R...

Re: placement of braces and "else" clauses. At the R prompt, I believe their placement must avoid causing a syntactically complete statement at the wrong place. This can results in what might be considered rather awkward looking code. IF it is known that code will be used via sourcing a script only, is there...

...db) r Starting program: a.out [New Thread 0x1403 of process 23435] warning: unhandled dyld version (15) Thread 2 hit Breakpoint 1, main () at a.c:5 5 for (i = 0; i < 256; i++) (gdb) n 7 i++; (gdb) 5 for (i = 0; i < 256; i++) (gdb) 7 i++; That is to say, the right brace of location LLVM doesn't emit. However if we have the continue keyword: int main() { int i; for (i = 0; i < 256; i++) { continue; i++; } } Then we compile and debug it: Thread 2 hit Breakpoint 1, main () at a.c:5 5 for (i = 0; i < 256; i++) (gdb) n 7 continu...

As of r313998, this workflow no longer works: cd <build-dir> ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping I get: llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/lit.cfg.py:97: note: using clang: '/Volumes/Builds/llvm.org-coverage-braces-RA/bin/clang' llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/Users/vk/src/llvm.org-coverage-braces/llvm/tool...

Hello. Building R-patched from source on Win64 using current Rtools 3.5.0.4, I?m getting the following notes indicating an extra left brace somewhere; or is the problem on my end? My installed Perl is Strawberry 5.28.0.1-64 bit. Thank you, Avi (Sent from an iPhone, so my apologies if HTML also comes through) ------ Making HTML documentation ------ creating doc/manual/version.texi creating doc/manual/R-FAQ.html Unescaped left br...

Dear developers, while preparing to submit a package to CRAN, I noticed that a check for lost braces in Rd files (which is enabled in the current r-devel when checking with the '--as-cran' option) seems to return false positives. More specifically, a 'Lost braces' NOTE is issued (at least sometimes) when using the \insertRef{...}{...} command from the Rdpack package. Since the...