search for: codingstandard

According to the LLVM coding standards, Immediately after the header file comment <http://llvm.org/docs/CodingStandards.html#header-file-comment> (and include guards if working on a header file), the minimal list of #includes <http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes>required by the file should be listed. We prefer these #includes to be listed in this order: 1. Main Module Hea...

...ked with various contributors privately, I have found no one who says they likes capitalized variables. It seems like everyone thinks the conventions are carved in stone... My proposal is that we modify the LLVM Coding Conventions to have variable names start with a lowercase letter. Index: CodingStandards.rst =================================================================== --- CodingStandards.rst (revision 219065) +++ CodingStandards.rst (working copy) @@ -1073,8 +1073,8 @@ nouns and start with an upper-case letter (e.g. ``TextFileReader``). * **Variable names** should be nouns (as they re...

...d need to run on a target. It's unlikely exceptions would get in in a random patch, because it would have to change the makefile; but even so, it would be useful to know that it's due to a definite design rule (assuming that's the case). Maybe this could be added to http://llvm.org/docs/CodingStandards.html ? Al -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy th...

...ibutes NoReturn (1<<2); ///< Mark the function as not returning We really don't like static ctors in LLVM, because it is often used as a library, and they cause startup-time performance hits and other bad news. I'm surprised we don't have an explicit section about it in the CodingStandards, but we do have: http://llvm.org/docs/CodingStandards.html#ll_iostream ... which talks about the same thing. Anyway, as it turns out, LLVM can optimize those static ctors away in some cases, but not all (e.g. -O0). This was found because LLDB builds with -Wstatic-constructor and this header cha...

...arget. > It's unlikely exceptions would get in in a random patch, because it would > have to change the makefile; but even so, it would be useful to know that > it's due to a definite design rule (assuming that's the case). > Maybe this could be added to http://llvm.org/docs/CodingStandards.html ? yes, it's a definite design rule. Can you please send a doc patch for CodingStandards with some appropriate text in it. Thanks a lot, Duncan.

...It's unlikely exceptions would get in in a random patch, because it would >> have to change the makefile; but even so, it would be useful to know that >> it's due to a definite design rule (assuming that's the case). >> Maybe this could be added to http://llvm.org/docs/CodingStandards.html ? > > yes, it's a definite design rule.  Can you please send a doc patch for > CodingStandards with some appropriate text in it. > > Thanks a lot, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiu...

...-dev] LLVM coding standards and order of includes On Thu, Sep 10, 2015 at 8:06 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: According to the LLVM coding standards, Immediately after the <http://llvm.org/docs/CodingStandards.html#header-file-comment> header file comment (and include guards if working on a header file), the <http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes> minimal list of #includesrequired by the file should be listed. We prefer these #includes to be listed in this order:...

...an actual code review on llvm-commits since it seems like it could do with a bit of a wider discussion, but once/if the general direction is agreed on, I'll send a patch for review of specific wording for the LLVM Coding Standards. Currently the LLVM Coding Standards <https://llvm.org/docs/CodingStandards.html> doesn't say much/anything about layering. 'A Public Header File *is* a Module' <https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module> section talks about modules of functionality, mostly trying to describe why a header file should be self contained...

Siddharth, I'm not sure what coding standards you refer to when you say "some C++ coding standard". This question is answered in the LLVM Coding Standards document here: https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions <https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions> As such LLVM's coding standards prohibit the use of exceptions and RTTI. -Chris > On May 1, 2018, at 10:02 AM, Siddharth Shankar Swain via llvm-dev <llvm-dev at list...

Hi everyone, I have a code style question: should full test programs (.c,.cpp files) use the documented CamelCase from http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly or instead use lower_with_underscores as I've been told the .ll lit test files should use? I see both in existing files, and in particular for projects/compiler-rt I cannot blindly follow the existing code as the existing sanitizers...

...lt;2); ///< Mark the function as not returning > > We really don't like static ctors in LLVM, because it is often used as a > library, and they cause startup-time performance hits and other bad news. > I'm surprised we don't have an explicit section about it in the > CodingStandards, but we do have: > http://llvm.org/docs/CodingStandards.html#ll_iostream > > ... which talks about the same thing. > > Anyway, as it turns out, LLVM can optimize those static ctors away in some > cases, but not all (e.g. -O0). This was found because LLDB builds with > -Wstati...

Hi all, Can anyone explain why exceptions are disabled in LLVM, even if some C++ coding standard tells to use exceptions ? Thanks, Siddharth -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180501/ed7903db/attachment-0001.html>

...ion: + CallSite CS = CallSite::get(C); + + // Pointer must be a parameter (case 1) + for (argI = 0; argI < CS.arg_size(); ++argI) + if (CS.getArgument(argI)->stripPointerCasts() == pointer) + break; + + if (argI == CS.arg_size()) + return false; per http://llvm.org/docs/CodingStandards.html#hl_predicateloops + // Store cannot be volatile (case 2) and must-alias with our pointer. + if (S->isVolatile()) { + return false; + } else { no need for the 'else after return': http://llvm.org/docs/CodingStandards.html#hl_else_after_return + AliasAnalysis...

http://llvm.org/releases/2.0/docs/CodingStandards.html I just realized that the target version is LLVM 2.0, so most likely the llvm::StringStream is deprecated by now. Thanks for your response! On 12/10/2011, at 17:10, Garrison Venn wrote: > Hi Pablo, > > Can you provide a link to the document containing a reference to > llvm::S...

...hris Bieneman <chris.bieneman at me.com> wrote: > Siddharth, > > I'm not sure what coding standards you refer to when you say "some C++ > coding standard". This question is answered in the LLVM Coding Standards > document here: > > https://www.llvm.org/docs/CodingStandards.html#do-not- > use-rtti-or-exceptions > > As such LLVM's coding standards prohibit the use of exceptions and RTTI. > > -Chris > > On May 1, 2018, at 10:02 AM, Siddharth Shankar Swain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > Can an...

...an actual code review on llvm-commits since it seems like it could do with a bit of a wider discussion, but once/if the general direction is agreed on, I'll send a patch for review of specific wording for the LLVM Coding Standards. Currently the LLVM Coding Standards<https://llvm.org/docs/CodingStandards.html> doesn't say much/anything about layering. 'A Public Header File is a Module'<https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module> section talks about modules of functionality, mostly trying to describe why a header file should be self contained -...

...ommits since it seems like it could do with a bit of a wider > discussion, but once/if the general direction is agreed on, I'll send > a patch for review of specific wording for the LLVM Coding Standards. > > > Currently the LLVM Coding Standards > <https://llvm.org/docs/CodingStandards.html> doesn't say much/anything > about layering. 'A Public Header File *is* a Module' > <https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module> section > talks about modules of functionality, mostly trying to describe why a > header file...

...m-commits since it seems like it could do with a bit of a wider > discussion, but once/if the general direction is agreed on, I'll send a > patch for review of specific wording for the LLVM Coding Standards. > > > Currently the LLVM Coding Standards > <https://llvm.org/docs/CodingStandards.html> doesn't say much/anything > about layering. 'A Public Header File *is* a Module' > <https://llvm.org/docs/CodingStandards.html#a-public-header-file-is-a-module> section > talks about modules of functionality, mostly trying to describe why a > header file shou...

Hi Pablo, Can you provide a link to the document containing a reference to llvm::StringStream? I've looked in both the llvm coding standards, and llvm programming manual for versions: ToT (3.0), 2.9 (which seems to be the same as ToT), and 2.8. Obviously my search is missing something. Thanks in advance Garrison On Oct 12, 2011, at 8:18, Pablo Barrio wrote: > Hi, > > I need

...n at me.com <mailto:chris.bieneman at me.com>> wrote: > Siddharth, > > I'm not sure what coding standards you refer to when you say "some C++ coding standard". This question is answered in the LLVM Coding Standards document here: > > https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions <https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions> > > As such LLVM's coding standards prohibit the use of exceptions and RTTI. > > -Chris > >> On May 1, 2018, at 10:02 AM, Siddharth Shankar Swain via...