search for: emplacing

Hi everyone, I would like to start a discussion about enforcing use of clang-tidy (or better clang-tidy-diff) on patches before sending it to review. I like how clang-format simplified sending patches and reviews, e.g. "Use clang-format" instead of giving long list of lines that should be formatted by reviewer. I believe that clang-tidy can be also be very helpful here. Note that by

I'm a bit confused by this whole discussion. clang-format is neither mandated (by documentation) nor enforced (by any infrastructure/automation) for use in the LLVM project that I know of. It's convenient, and in review people may reasonably ask authors to consider running it, etc - but we have no system that requires or checks for that. Might be nice, might not be. It sounds like even

> > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability. > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come to some agreement about what should be written in the first place, preferably

Hi, I've setup a transparent HTTP+HTTPS proxy on my server running CentOS 7, using Squid. Here's my configuration file. --8<---------------------------------------------------------------- # /etc/squid/squid.conf # D?finitions acl localnet src 192.168.2.0/24 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port

> On Dec 29, 2016, at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: >> >>

On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back > everywhere to make code easier to maintain. I think it is valid argument, > but I believe it would reduce readability.

> On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > From yesterday discussion, Daniel Berlin proposed using emplace_back everywhere to make code easier to maintain. I think it is valid argument, but I believe it would reduce readability. > > Just to be clear; I proposed not trying to switch uses back and forth without real data, and to come

According to the documentation at http://llvm.org/docs/GettingStarted.html#software, compiling LLVM with GCC requires at least version 4.7.0. However, there are apparently several problems building current LLVM/Clang with gcc 4.7.X. This proposal is to increase the minimum required GCC to 4.8. This is split off of the thread started here:

On Thu, Dec 29, 2016 at 11:46 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Dec 29, 2016, at 11:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Dec 29, 2016 at 10:04 AM Mehdi Amini via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > On Dec 29, 2016, at 5:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > >

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

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr. Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode. You'll be able to get it back with a "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" on your command line, or "#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" before including any libc++ header

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

Hello, Some weeks ago, thanks to you, I managed to install R, to connect to a local MySQL Database and to launch some queries with a script written with Tinn-R. My script is now ok and would like to test it with the "real" database. I did the same installation of R, DBI package and RMySQL package I did on my PC (I wrote everything I did in order to make it easy ...) but when I type

2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi Piotr, >> >> I think makes sense. Modulo bitcasts, the invariant is identified by a >> particular pointer SSA value. Given that you can't sensibly have two >> nonequivalent

LLVM Weekly - #130, Jun 27th 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/130>. Welcome to the one hundred and thirtieth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

Dear Community, The patch for Interprocedural Register Allocation has been committed now , thanks to Mehdi Amini for that. We would like you to play with it and let us know your views and more importantly ideas to improve it. The test-suite run has indicated some non trivial issue that results in run time failure of the programs, we will be investigating it more. Here are some stats :

2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov>: > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: > > > > 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk>: > >> On 25 January 2017 at 15:03, Hal Finkel via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> Hi Piotr, >>> >>> I think

On Wed, Jun 15, 2016 at 6:16 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Vivek, > > How much of the slow down on runtime comes from the different layout of > the function in the asm file? (I.e., because of the dummy scc pass.) > > Hello Quentin, Please do not consider previous results as there was a major bug in RegMask calculation due to not considering

On 01/28/2017 10:36 AM, Piotr Padlewski wrote: > > > 2017-01-26 15:41 GMT+01:00 Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>>: > > > On 01/26/2017 06:44 AM, Piotr Padlewski wrote: >> >> >> 2017-01-26 3:28 GMT+01:00 Richard Smith <richard at metafoo.co.uk >> <mailto:richard at metafoo.co.uk>>: >>