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 <https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/> . Language wise, 2015 comes with a lot of new C++ features. The most interesting to people will probably be template aliases, C++11 constexpr, the thread_local keyword, and thread-safe function local statics (finally). A complete list of new C++ language support can be found here <https://msdn.microsoft.com/en-us/library/hh409293.aspx>. As far as the different LLVM subprojects are concerned, LLDB was always going to be the hardest get working with MSVC 2015 due to the fact that it embeds python as an extension module, but as the LLDB maintainer for Windows I tackled this early and I can say that it's now done and we have completely transitioned to MSVC 2015 already in LLDB. Since we are only supporting 2015 in LLDB moving forward, I have a slight preference to bumping this in LLVM sooner rather than later, but I'd like to hear other peoples' thoughts on the matter as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/f328b2b0/attachment.html>
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 Visual Studio unless there is a strong use case for dropping the oldest version. I don't believe any such use case has been brought up yet, so I would imagine we will continue to support MSVC 2013 until the next major release.> Language wise, 2015 comes with a lot of new C++ features. The most > interesting to people will probably be template aliases, C++11 constexpr, > the thread_local keyword, and thread-safe function local statics (finally). > A complete list of new C++ language support can be found here. > > As far as the different LLVM subprojects are concerned, LLDB was always > going to be the hardest get working with MSVC 2015 due to the fact that it > embeds python as an extension module, but as the LLDB maintainer for Windows > I tackled this early and I can say that it's now done and we have completely > transitioned to MSVC 2015 already in LLDB. > > Since we are only supporting 2015 in LLDB moving forward, I have a slight > preference to bumping this in LLVM sooner rather than later, but I'd like to > hear other peoples' thoughts on the matter as well.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 supporting default arguments, the AST matcher DSL made for really slow compiles of Clang itself, and resulted in a larger executable size among other things, IIRC). I recall we had frequent build breaks from MSVC 2012 not supporting basic C++11 language features or miscompiling due to early support. I've not seen that be the case with MSVC 2013 except for the occasional issue with use of braced initializer lists. Coupled with the fact that there's no future version of MSVC with an imminent release, I would prefer to not bump unless it starts significantly stifling our development efforts. ~Aaron
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 were in a bit of a bind. The only practical solution for us was to support Python 3.5 (which is compiled with VC 2015 and solves the compiler / ABI compatibility problem through the UCRT). Granted this was a bit of a special circumstance, but as it stands I am already calling VC 2013 "unsupported" for LLDB. On Tue, Mar 29, 2016 at 10:42 AM Aaron Ballman <aaron at aaronballman.com> wrote:> 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 Visual > Studio unless there is a strong use case for dropping the oldest > version. I don't believe any such use case has been brought up yet, so > I would imagine we will continue to support MSVC 2013 until the next > major release. > > > Language wise, 2015 comes with a lot of new C++ features. The most > > interesting to people will probably be template aliases, C++11 constexpr, > > the thread_local keyword, and thread-safe function local statics > (finally). > > A complete list of new C++ language support can be found here. > > > > As far as the different LLVM subprojects are concerned, LLDB was always > > going to be the hardest get working with MSVC 2015 due to the fact that > it > > embeds python as an extension module, but as the LLDB maintainer for > Windows > > I tackled this early and I can say that it's now done and we have > completely > > transitioned to MSVC 2015 already in LLDB. > > > > Since we are only supporting 2015 in LLDB moving forward, I have a slight > > preference to bumping this in LLVM sooner rather than later, but I'd > like to > > hear other peoples' thoughts on the matter as well. > > 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 > supporting default arguments, the AST matcher DSL made for really slow > compiles of Clang itself, and resulted in a larger executable size > among other things, IIRC). I recall we had frequent build breaks from > MSVC 2012 not supporting basic C++11 language features or miscompiling > due to early support. I've not seen that be the case with MSVC 2013 > except for the occasional issue with use of braced initializer lists. > Coupled with the fact that there's no future version of MSVC with an > imminent release, I would prefer to not bump unless it starts > significantly stifling our development efforts. > > ~Aaron >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/6d17b51b/attachment.html>
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: "Zachary Turner via llvm-dev" <llvm-dev at lists.llvm.org> Sent: 3/29/2016 1:30 PM To: "llvm-dev" <llvm-dev at lists.llvm.org> Subject: [llvm-dev] Upgrading to MSVC 2015 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. Language wise, 2015 comes with a lot of new C++ features. The most interesting to people will probably be template aliases, C++11 constexpr, the thread_local keyword, and thread-safe function local statics (finally). A complete list of new C++ language support can be found here. As far as the different LLVM subprojects are concerned, LLDB was always going to be the hardest get working with MSVC 2015 due to the fact that it embeds python as an extension module, but as the LLDB maintainer for Windows I tackled this early and I can say that it's now done and we have completely transitioned to MSVC 2015 already in LLDB. Since we are only supporting 2015 in LLDB moving forward, I have a slight preference to bumping this in LLVM sooner rather than later, but I'd like to hear other peoples' thoughts on the matter as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/b1254e0f/attachment.html>
On Tue, Mar 29, 2016 at 3:52 PM, Alexander Riccio via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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.Yes, we require the latest updates to be installed, though we don't currently document it (I'll go fix that). ~Aaron> > sent from my (stupid) windows phone > ________________________________ > From: Zachary Turner via llvm-dev > Sent: 3/29/2016 1:30 PM > To: llvm-dev > Subject: [llvm-dev] Upgrading to MSVC 2015 > > 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. > > Language wise, 2015 comes with a lot of new C++ features. The most > interesting to people will probably be template aliases, C++11 constexpr, > the thread_local keyword, and thread-safe function local statics (finally). > A complete list of new C++ language support can be found here. > > As far as the different LLVM subprojects are concerned, LLDB was always > going to be the hardest get working with MSVC 2015 due to the fact that it > embeds python as an extension module, but as the LLDB maintainer for Windows > I tackled this early and I can say that it's now done and we have completely > transitioned to MSVC 2015 already in LLDB. > > Since we are only supporting 2015 in LLDB moving forward, I have a slight > preference to bumping this in LLVM sooner rather than later, but I'd like to > hear other peoples' thoughts on the matter as well. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
On Tue, Mar 29, 2016 at 10:42 AM, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 Visual > Studio unless there is a strong use case for dropping the oldest > version. I don't believe any such use case has been brought up yet, so > I would imagine we will continue to support MSVC 2013 until the next > major release. > > > Language wise, 2015 comes with a lot of new C++ features. The most > > interesting to people will probably be template aliases, C++11 constexpr, > > the thread_local keyword, and thread-safe function local statics > (finally). > > A complete list of new C++ language support can be found here. > > > > As far as the different LLVM subprojects are concerned, LLDB was always > > going to be the hardest get working with MSVC 2015 due to the fact that > it > > embeds python as an extension module, but as the LLDB maintainer for > Windows > > I tackled this early and I can say that it's now done and we have > completely > > transitioned to MSVC 2015 already in LLDB. > > > > Since we are only supporting 2015 in LLDB moving forward, I have a slight > > preference to bumping this in LLVM sooner rather than later, but I'd > like to > > hear other peoples' thoughts on the matter as well. > > 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 > supporting default arguments, the AST matcher DSL made for really slow > compiles of Clang itself, and resulted in a larger executable size > among other things, IIRC). I recall we had frequent build breaks from > MSVC 2012 not supporting basic C++11 language features or miscompiling > due to early support. I've not seen that be the case with MSVC 2013 > except for the occasional issue with use of braced initializer lists. >The most common one I see here ^ is MSVC 2013's inability to generate implicit definitions of move special members. Comes up pretty regularly.> Coupled with the fact that there's no future version of MSVC with an > imminent release, I would prefer to not bump unless it starts > significantly stifling our development efforts. > > ~Aaron > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160329/19cf2da9/attachment.html>
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 > supporting default arguments, the AST matcher DSL made for really slow > compiles of Clang itself, and resulted in a larger executable size > among other things, IIRC).I know you mentioned that one of the reasons we upgraded to 2013 was because 2015 was in RC or RTM. Ironically, the day after I posted this MS announced Visual Studio 15 preview <https://www.visualstudio.com/news/vs15-preview-vs> (which is confusingly the version *after* Visual Studio 2015). In any case, it's not an RC, and it's certainly not an RTM, but it is on the horizon. So hopefully we can revisit this question when 15 is in RC / RTM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160331/d0eb1e5b/attachment.html>