similar to: Upgrading to MSVC 2015

On Tue, Mar 29, 2016 at 1:29 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think it's been a little over a year since we bumped the minimum VS > version to 2013. Are we planning to do the same for 2015? Update 2 is > releasing soon, which is stable enough at least to ship Chromium. In the past, we've supported the latest two major versions of

I can tell you that at least on the LLDB side, it was significantly stifling our development efforts. The requirement that embedding Python means you have to compile Python with the same compiler that you compile the program you're embedding it in, and the fact that the only supported toolchain for Python 2.7 is VC 2008, and the fact that Python 2.7 doesn't even compile with VC 2015, we

Btw, I can't remember if this is explicit in the documentation: Does LLVM require the latest two *updated* versions of Visual Studio? (i.e. VS2013 update 5 & VS 2015 update 1) I've seen people on the mailing list several times running an out of date version, which is nonsensical, and could cause strange problems. sent from my (stupid) windows phone -----Original Message----- From:

FWIW, no objections from me, after all I proposed this 3 months ago :) Probably Aaron Ballman should comment though since the primary objection last time was his. On Fri, Jul 29, 2016 at 2:00 PM Sean Silva <chisophugis at gmail.com> wrote: > On Fri, Jul 29, 2016 at 1:23 PM, Robinson, Paul via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There are certainly

> -----Original Message----- > From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf > Of Aaron Ballman > Sent: Friday, July 29, 2016 2:19 PM > To: Zachary Turner > Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Upgrading to MSVC 2015 > > There are not that many people making commits to

There are not that many people making commits to working around MSVC 2013 as I think are claimed (there are certainly a lot of commits for working around MSVC in general, however). A quick search through the code base shows there are 8 instances where we've worked around MSVC 2013 issues (there may be more that someone worked around in an ad hoc manner and did not mark). We definitely had *a

On Sat, Jul 30, 2016 at 1:58 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > >> -----Original Message----- >> From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf >> Of Aaron Ballman >> Sent: Friday, July 29, 2016 2:19 PM >> To: Zachary Turner >> Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev at

> -----Original Message----- > From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf > Of Aaron Ballman > Sent: Saturday, July 30, 2016 12:41 PM > To: Robinson, Paul > Cc: Zachary Turner; Sean Silva; Piotr Padlewski; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Upgrading to MSVC 2015 > > On Sat, Jul 30, 2016 at 1:58 PM, Robinson, Paul

On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote: >> Creating constexpr StringRefs isn't trivial as strlen isn't portably >> constexpr and std::char_traits<char>::length is only constexpr in >> C++17. > > Why don't we just create our own traits class that has a constexpr length, and then we can switch over to the standard one when

OK - good to know. (not sure we're talking about pessimizing it - just not adding a new/possible optimization, to be clear) Just out of curiosity - are there particular reasons you prefer or need to ship an MSVC built version, rather than a bootstrapped Clang? On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com> wrote: > So I wouldn't personally worry too

On Fri, Nov 25, 2016 at 6:10 AM Mueller-Roemer, Johannes Sebastian via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What about going for > > template<unsigned N> > constexpr StringRef(const char (&Str)[N]) > > and avoiding strlen entirely for string literals? > You'd at least want an assert in there (that N - 1 == strlen(Str)) in case a StringRef is

https://www.visualstudio.com/en-us/news/vs2015-vs.aspx Is it time? 2016-03-31 12:03 GMT-07:00 Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org>: > On Thu, Mar 31, 2016 at 2:57 PM, Zachary Turner <zturner at google.com> > wrote: > > > > > > On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman <aaron at aaronballman.com> > > wrote: > >>

On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > Not everyone can upgrade to the latest version of the toolchain, even > if it has been released for a while. We did drop MSVC 2012 support > early, but MSVC 2015 was in RC or RTM stages by that point, and we had > some pretty big incentive to upgrade early (without function templates >

On Mon, Nov 28, 2016 at 11:01 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Nov 28, 2016, at 9:47 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > OK - good to know. (not sure we're talking about pessimizing it - just not > adding a new/possible optimization, to be clear) > > > This does not seem that clear to me. The

There are certainly enough people making commits that work with VS2015 but not VS2013 that the "would it be useful" question is pretty well answered. I've already brought up the idea on my team, as it's obviously coming and we need time to coordinate with internal consumers of the toolchain. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Zachary

The fact that the templatized constructor falls down because of the possibility of initializing StringRef with a stack-allocated char array kills that idea in my mind. I feel like the only two reasonable solutions are 1) allow UDL for this case, document that this is an exception and that UDLs are still not permitted anywhere else, and require (by policy, since I don't know of a way to have

On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> > wrote: > > > > well, top-of-branch lldb uses this code, that's how I found it. Do you > mean libc++'s demangler? > > Thanks for explaining, this is the first time

Probably not. It's very confusing because they are transitioning to a new versioning scheme. The current version if Visual Studio 2015. The next version is Visual Studio 15. The link you posted was for the RTM of 2015, just over a year ago. But 15 is still in Preview. When 15 goes to RTM, then we can revisit the question of making 2015 the minimum required version. On Fri, Jul 29, 2016

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {

On Thu, Mar 31, 2016 at 2:57 PM, Zachary Turner <zturner at google.com> wrote: > > > On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman <aaron at aaronballman.com> > wrote: >> >> >> Not everyone can upgrade to the latest version of the toolchain, even >> if it has been released for a while. We did drop MSVC 2012 support >> early, but MSVC 2015 was