search for: braces

Displaying 20 results from an estimated 954 matches for "braces".

Did you mean: races
2020 Jun 22
7
Codifying our Brace rules-
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 for less-than-fully-braced statement -- the preference s...
2020 Jun 22
4
Codifying our Brace rules-
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 brace...
2020 Jun 23
3
Codifying our Brace rules-
...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 stateme...
2020 Jun 23
2
Codifying our Brace rules-
...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...
2020 Jun 16
3
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 involve...
2020 Jun 15
2
Codifying our Brace rules-
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 suf...
2020 Jun 23
2
Codifying our Brace rules-
...0, 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't register any technical arguments for less-than-fully-br...
2020 Jun 24
4
Codifying our Brace rules-
...re 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 clear we can be. > I think we should take the suggestion of “always require braces” off the > table, because it doesn’t make sense given the impact to the code base. > Given that the codebase is already riddled with inconsistencies (and instances that I cannot determine the correctness against the current guidelines), I don't understand why you think it doesn't mak...
2020 Jun 16
3
Codifying our Brace rules-
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 (co...
2020 Jul 01
2
Codifying our Brace rules-
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 i...
2020 Jun 23
3
Codifying our Brace rules-
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 switc...
2020 Jun 15
9
Codifying our Brace rules-
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 commit...
2017 Jun 03
3
How the LLVM handle the debug location information of continue keyword and right brace(loop end location)?
...ation information. But the br instruction is the same and only has different line number information in the debug metadata, how the llvm distinguish this is meaningful statement and not right brace? At 2017-06-03 02:50:13, "Robinson, Paul" <paul.robinson at sony.com> wrote: The braces around the body of the 'for' statement indicate grouping, but don't have any other semantic significance. If you look at the abstract syntax tree (AST) constructed for this by any compiler, it is highly unlikely to have an explicit representation of the braces, because the structure of...
2020 Jun 29
3
Codifying our Brace rules-
...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....
2017 Jun 05
2
How the LLVM handle the debug location information of continue keyword and right brace(loop end location)?
...ases: `}` is not a statement. `continue` is. In the first case, `br` does not correspond to the `}` itself, but rather to a natural BB termination. In the latter, `br` explicitly corresponds to the `continue`. If you still wonder what is the difference, look at the IR in the third case: without any braces. Where would you expect the debug information to be? Cheers, Marcin 2017-06-03 15:46 GMT+02:00 Frozen <bluechristlove at 163.com<mailto:bluechristlove at 163.com>>: Hi Marcin: I don't expect stop the right brace } and expect stop at continue keyword statement. My question is...
2006 Oct 25
2
Coding style query (braces)
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...
2017 Jun 02
2
How the LLVM handle the debug location information of continue keyword and right brace(loop end location)?
Let me show you the following simple C code: int main() { int i; for (i = 0; i < 256; i++) { i++; } } In this simple C code, if we use Clang to compile it and debug it: We will get something like this: (gdb) b main Breakpoint 1 at 0x100000f7b: file a.c, line 5. (gdb) r Starting program: a.out [New Thread 0x1403 of process 23435] warning: unhandled dyld version (15) Thread 2
2017 Sep 22
2
No longer able to run lit tests within a sub-tool
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/tools...
2018 Dec 26
1
Issue when building R-parched_2018-12-26
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
2023 Nov 07
2
False positives in check for lost braces (in tools::checkRd())
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...