search for: ispodlike

...ing has been migrated yet) then just > make clang-format agree with reality - this doesn't require a > discussion or bikeshed. > It's not overwhelming, but the preponderance seems to be towards putting it on its own line (the exceptions are usually small trait specializations like isPodLike). I give some rough numbers here < http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378> (and see Daniel's reply). Daniel is open to changing it, but asked me to gather some more opinions. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... U...

...t setting of `AlwaysBreakTemplateDeclarations: false` for LLVMStyle intentional? What was the rationale? Some rough counts on the LLVM codebase: same-line: $ git grep -E 'template.*(class|struct).*{' -- '*.h' '*.cpp' | wc -l 214 (most of them are tiny traits classes, like isPodLike or DenseMapInfo) not-same-line: $ git grep -A1 -h 'template' -- '*.h' '*.cpp' | egrep '^\s*(class|struct).*{' | wc -l 622 Recently, when using clang-format I've had to manually go back and change cases where clang-format does not put the `template <...>`...

I did a make update. I thought I was running the newest version of compiler-rt. But now I can't even get the project to build. I get the following error: i386-redhat-linux-gnu-clang++: clang/llvm/include/llvm/ADT/SmallVector.h:544: typename llvm::SmallVectorTemplateBase<T, llvm::isPodLike::value>::iterator llvm::SmallVectorImpl<T>::insert(typename llvm::SmallVectorTemplateBase<T, llvm::isPodLike::value>::iterator, const T&) [with T = const char*]: Assertion `I <= this->end() && "Inserting past the end of the vector."' failed. 0 i386-re...

...then just >> make clang-format agree with reality - this doesn't require a >> discussion or bikeshed. > > > It's not overwhelming, but the preponderance seems to be towards putting it > on its own line (the exceptions are usually small trait specializations like > isPodLike). I give some rough numbers here > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378> Fair enough - could we draw any further stylistic conclusions that could motivate clang-format? If the entire definition of the template fits on one line is it pretty consistent that it'...

....h (original) > +++ llvm/trunk/include/llvm/ADT/Optional.h Thu Jan 18 03:26:24 2018 > @@ -27,139 +27,173 @@ > > namespace llvm { > > -template <typename T> class Optional { > +namespace optional_detail { > +/// Storage for any type. > +template <typename T, bool IsPodLike> struct OptionalStorage { > AlignedCharArrayUnion<T> storage; > bool hasVal = false; > > -public: > - using value_type = T; > - > - Optional(NoneType) {} > - explicit Optional() {} > - > - Optional(const T &y) : hasVal(true) { new (storage.buffer...

...k/include/llvm/ADT/Optional.h Thu Jan 18 03:26:24 2018 >> @@ -27,139 +27,173 @@ >> >> namespace llvm { >> >> -template <typename T> class Optional { >> +namespace optional_detail { >> +/// Storage for any type. >> +template <typename T, bool IsPodLike> struct OptionalStorage { >> AlignedCharArrayUnion<T> storage; >> bool hasVal = false; >> >> -public: >> - using value_type = T; >> - >> - Optional(NoneType) {} >> - explicit Optional() {} >> - >> - Optional(const T &amp...

...ee with reality - this doesn't require a > >> discussion or bikeshed. > > > > > > It's not overwhelming, but the preponderance seems to be towards putting > it > > on its own line (the exceptions are usually small trait specializations > like > > isPodLike). I give some rough numbers here > > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378> > > Fair enough - could we draw any further stylistic conclusions that > could motivate clang-format? If the entire definition of the template > fits on one line is it pretty...

...03:26:24 2018 > >> @@ -27,139 +27,173 @@ > >> > >> namespace llvm { > >> > >> -template <typename T> class Optional { > >> +namespace optional_detail { > >> +/// Storage for any type. > >> +template <typename T, bool IsPodLike> struct OptionalStorage { > >> AlignedCharArrayUnion<T> storage; > >> bool hasVal = false; > >> > >> -public: > >> - using value_type = T; > >> - > >> - Optional(NoneType) {} > >> - explicit Optional() {} >...

+kcc, llvmdev I think your compiler-rt checkout is out of date, because r188635 is supposed to fix that exact issue. On Mon, Aug 19, 2013 at 9:16 PM, Sharma, Yogesh < Yogesh.Sharma at saabsensis.com> wrote: > Sorry about that. I forgot a d:**** > > ** ** > > ldd (GNU libc) 2.12**** > > Copyright (C) 2010 Free Software Foundation, Inc.**** > > This is free

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

...a >> >> discussion or bikeshed. >> > >> > >> > It's not overwhelming, but the preponderance seems to be towards putting >> > it >> > on its own line (the exceptions are usually small trait specializations >> > like >> > isPodLike). I give some rough numbers here >> > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378> >> >> Fair enough - could we draw any further stylistic conclusions that >> could motivate clang-format? If the entire definition of the template >> fits on o...

On Mon, Jul 1, 2013 at 2:21 PM, Sean Silva <silvas at purdue.edu> wrote: > tl;dr If there are no objections I'd like to change clang-format's LLVM > style to always put `template <...>` on its own line. I think it's a general > code-layout consistency win and avoids some cases where trivial code changes > result in significant formatting differences (see the

GNU ld version 2.20.51.0.2-5.36.el6 20100205 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. From: Kostya Serebryany [mailto:kcc at google.com] Sent: Monday, August 19, 2013 5:36 AM To: Sergey Matveev Cc:

tl;dr If there are no objections I'd like to change clang-format's LLVM style to always put `template <...>` on its own line. I think it's a general code-layout consistency win and avoids some cases where trivial code changes result in significant formatting differences (see the last example). Examples of the current behavior: -------------- template <class ELFT> class