similar to: [LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed

On Mar 1, 2014, at 7:15 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Sat, Mar 1, 2014 at 5:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > The current guidelines [1] on the use of the struct keyword are too > restrictive and apparently ignored. They limit the use of struct to > PODs, citing broken compilers. > > The guidelines are

On Sun, Feb 3, 2019 at 6:50 AM Stephen Kelly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 31/12/2018 04:54, Chris Lattner via llvm-dev wrote: > >> Do those uses conform to the guide? If they don't, then should the > guide be updated? Are the types there 'obvious’? > > > > If/when we revise the policy, then it would make sense for >

On 6 March 2015 at 18:33, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Renato, > > Did anything ever happen with this? Nope. People didn't want to commit to limits but still have a guideline. I'm of the view that guidelines are meant to be ignored. Do you want to continue pushing this? cheers, --renato

----- Original Message ----- > From: "Reid Kleckner" <rnk at google.com> > To: "Renato Golin" <renato.golin at linaro.org> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Clang Dev" <cfe-dev at cs.uiuc.edu>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 6, 2015 2:59:54 PM > Subject: Re: [cfe-dev]

Hi, The LLVM coding style does not specify anything about the use of signed/unsigned integer, and the codebase is inconsistent (there is a majority of code that is using unsigned index in loops today though). I'd like to suggest that we specify to prefer `int` when possible and use `unsigned` only for bitmask and when you intend to rely on wrapping behavior, see:

Do local lambdas get named like variables or like functions? E.g. void foo() { auto helper = [](...){...}; // or auto Helper = [](...){...}; } My gut is that it should be lowercase (named like a function) since I got a weird feeling in my stomach seeing an upper-case name being called like a function in new code. -- Sean Silva -------------- next part -------------- An HTML attachment

It looks like Mark and others have addressed the development/CVS issues. We should let their plan be put into effect and give it a chance to work. Regarding the email list: A number of people have suggested creating more email lists. I think this is not a good idea because there will be even more cross posting than there is now between -dev and -users. Several years ago I was a moderator on the

I'm not advocating AAA. However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. Currently the rule on the use of auto is here: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It is quite strict. It allows the use of auto for * lambdas * iterators because they are long to type * casts to

Hello everyone! I'm in the process of writing a package, and I'm using the lovely "R Package" book as a guideline. However, in the midst of my work, I discovered that I had omitted a function and am now putting in it the package. Not a problem. But the problem is the help file. What is the best way to generate a help file "after the fact" like that, please? Thank

On 09/18/2018 11:03 AM, Fabiano Fid?ncio wrote: > My understanding is that we can use all the CentOS marks provided here[0]. > However, those unfortunately are not looking good enough on Boxes and > we'd like to use, if possible, just the logo as in here[1] > > Would that be possible? As far as I could understand that would be a > violation of the trademark. > > [0]:

G'day Erin, On Sat, 16 Dec 2017 08:00:38 -0600 Erin Hodgess <erinm.hodgess at gmail.com> wrote: > I'm in the process of writing a package, and I'm using the lovely "R > Package" book as a guideline. > > However, in the midst of my work, I discovered that I had omitted a > function and am now putting in it the package. Not a problem. But > the

On 27 October 2013 15:53, Chris Lattner <clattner at apple.com> wrote: > I'm not sure what you mean. Are your proposing that clang 3.4 use any > features supported by clang 3.3? If so, that won't work, because clang > can't self-host on all interesting architectures, e.g. it isn't fully ABI > compatible with Visual C++ (yet). > No, not yet. Certainly not

> On 2016-Feb-10, at 11:34, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Feb 10, 2016, at 11:32 AM, Harris, Kevin <Kevin.Harris at unisys.com> wrote: >> >>> From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] >>> Sent: Wednesday, February 10, 2016 1:51 PM >>> To: Duncan P. N. Exon Smith >>>

On Dec 16, 2018, at 11:44 AM, Stephen Kelly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 25/11/2018 14:43, Stephen Kelly via llvm-dev wrote: >> However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. >> Currently the rule on the use of auto is here: > > Hi, > > Thanks for the input on this topic,

On Tue, Oct 6, 2015 at 4:58 PM, Adrian Du?a <dusa.adrian at unibuc.ro> wrote: > Hi Gabriel, > > On Tue, Oct 6, 2015 at 10:59 PM, Gabriel Becker <gmbecker at ucdavis.edu> > wrote: > >> [...] >> >> At the very least, this is seems to be a flagrant violation of the >> *spirit* of the CRAN policy, which AFAIK is intended to enforce >>

Dear Achim, Thanks for the comment. Here is the publisher's style guideline (AGU) "Because the Internet is dynamic environment and sites may change or move, treat World Wide Web, ftp files, and electronically archived data stored at data centers other than World or National Data Centers as unpublished, i.e., in text only." http://www.agu.org/pubs/AuthorRefSheet.pdf So by this

<http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#RAID-Z_Configuration_Requirements_and_Recommendations> says that the number of disks in a RAIDZ should be (N+P) with N = {2,4,8} and P = {1,2}. But if you go down the page just a little further to the thumper configuration examples, none of the 3 examples follow this recommendation! I will have 10 disks to put into a

I notice that there's a lot of code in LLVM core libraries that is wildly inconsistent in formatting. Two particular things come to mind: -- Capitalization of method names. The LLVM guidelines say one thing, but a lot of recent code (such as IRBuilder) consistently does the opposite of what the guidelines say. One has to wonder which source of truth is more authoritative - after all, the docs

+llvmdev On Mar 7, 2014, at 5:15 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 03/07/2014 01:40 PM, Aaron Ballman wrote: >> On Thu, Mar 6, 2014 at 7:12 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >>> On Thu, Mar 6, 2014 at 7:10 PM, Tobias Grosser <tobias at grosser.es> wrote: >>>> I wonder if you could use 'auto const

On 18/09/2015 15:23, Ady via Syslinux wrote: > >> On Fri, Sep 18, 2015 at 02:01:32PM +0300, Ady via Syslinux wrote: >>>> >>>> We have pxechn.c32 working with pxelinux.0 to switch between the two >>>> system, but pxechn.c32 under Uefi come up with the folowing error >>> >>> >>> @Developers, please consider using 8.3