similar to: [LLVMdev] clang-format: `AlwaysBreakTemplateDeclarations: true` for LLVMStyle?

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

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

On Mon, Jul 1, 2013 at 2:31 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > Have you got any statistics for the current state of LLVM with respect > to this formatting issue? If something is already the overwhelmingly > common style (& it's not a case where it used to be the style, the > style has been updated, and nothing has been migrated yet) then just

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

On Mon, Jul 1, 2013 at 2:38 PM, Sean Silva <silvas at purdue.edu> wrote: > > > > On Mon, Jul 1, 2013 at 2:31 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> Have you got any statistics for the current state of LLVM with respect >> to this formatting issue? If something is already the overwhelmingly >> common style (& it's not

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

On Mon, Jul 1, 2013 at 2:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Jul 1, 2013 at 2:38 PM, Sean Silva <silvas at purdue.edu> wrote: > > > > > > > > On Mon, Jul 1, 2013 at 2:31 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> > >> Have you got any statistics for the current state of LLVM with

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

+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 Mon, Jul 1, 2013 at 3:41 PM, Sean Silva <silvas at purdue.edu> wrote: > > > > On Mon, Jul 1, 2013 at 2:40 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 1, 2013 at 2:38 PM, Sean Silva <silvas at purdue.edu> wrote: >> > >> > >> > >> > On Mon, Jul 1, 2013 at 2:31 PM, David Blaikie <dblaikie at

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 >

~~~ Not to be applied, for discussion only ~~~ I think we need some kind of "checkpatch" script to catch all the annoying, nitpicky code style issues that submitters trip up on. I looked at a few scripts that exist, primarily the ones from Linux and qemu (massive and complicated), and libvirt (small and sane). There are a couple of problems: (1) Linux/qemu-style checkpatch only

See previous version: https://www.redhat.com/archives/libguestfs/2016-April/msg00021.html The formatting in this second version isn't too bad. Still a few corner cases to sort out. Rich.

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:

On Thu, Jun 27, 2013 at 10:49 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Jun 27, 2013, at 10:12 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > > > > On Thu, Jun 27, 2013 at 9:50 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> > wrote: > > On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> >

E.g. Is it intended to be allowed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,

Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Anyone run into this before? I'm trying to get a Windows native build using Visual Studio of LLVM, Clang, and LLD 4.0.0. So far LLVM built successfully, but I'm getting these cryptic error messages when building Clang: Microsoft (R) Build Engine version 15.1.1012.6693 Copyright (C) Microsoft Corporation. All rights reserved. ClangDiagnosticsEmitter.cpp c:\program files

Here are two minor patches. The first adds an insert method to DenseSet that takes two iterators representing the beginning and ending of a range of items to insert. I lifted the code verbatim from DenseMap.h. The second patch defines DenseMapInfo for chars. This is useful because DenseSet is implemented as a DenseMap of (Type, char), so anyone who uses DenseSet has to define DenseMapInfo for