Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to 2013. The motivating reason is this will allow us to take advantage of a bunch of C++11 features that are not supported by MSVC 2012. According to MSDN (http://msdn.microsoft.com/en-us/library/hh567368.aspx) the list is:
Non-static data member initializers
Variadic templates
Initializer lists
Default template arguments for function templates
Expression SFINAE
Alias templates
Delegating constructors
Explicit conversion operators
Raw string literals
Defaulted and deleted functions
From the discussion on LLVM-dev it is also believed that this may ease some development pain as people keep occasionally breaking LLVM trunk by using language features not available in MSVC.
*we support building with the **most recent 2 versions of VS available at
the *prior* release. For example** when we branch for 3.4, the two versions
will be 2012 and 2013. Those two** would be supported on mainline from then
through 3.5, and when we branch** for 3.5 we would re-evaluate. *
If that is followed exactly support for VS2012 would not be able to be
dropped. However, it is rather easy to get the latest VC++ compiler from
Microsoft at no cost (Express edition anybody?), so I don't have any real
concern with dropping support for VS2012.
Officially, the latest two major versions- so MSVC 2012 and 2013.
The main issue I'd see here is that all of those features are relatively
untested- for example, in VS 14 CTP3 they had to introduce a new error to
explicitly break all the cases where the compiler silently did totally the
wrong thing. The ones that were included in VS2012 CTP are not quite as
bad. But the reality of using VS2013 is not that all of these features will
suddenly be available to use- there's a lot of compiler issues that would
need to be worked around, including some
silently-generates-totally-the-wrong-code bugs. They can also report
totally incorrect errors- e.g. reporting errors that have nothing to do
with the real error, in totally the wrong location, or both.
Seeing the feature list seems compelling, but MSVC's actual support is
often still below the standard you can find in GCC or Clang, even in
officially supported features. There's a price to be paid not just in terms
of breaking users who are still VS2012-dependent, but also in terms of
debugging VS2013-only bugs.
Personally, I think that it's worth upping the minimum requirement whenever
you're not breaking a substantial portion of your userbase. All I'm saying
is, the experience of many of us using VS2013 is that that feature list is
a little ... optimistic. Upgrading on that basis alone may well yield
undesirable results.
Perhaps it would be better to consider a fork, where the new features are
employed, and then if it doesn't introduce new bugs, it could be merged.
This would also give more time for people to report in with a VS2012
dependency.
I don’t think we should follow the 2-year rule for Windows. It really is special for at least three reasons: 1) We can’t bootstrap on Windows. While there is tons of exciting work going on here to change that, even then the quality of Windows support is likely to change very rapidly. 2) Visual Studio’s C++ support moved very slowly for a long time, and is now improving at an amazing rate. We shouldn’t be hampered by past problems and should take advantage of this recent progress. 3) We have less insight into when new versions of the MSVC++ toolchain will arrive.
I feel it is also worth recognizing that by the time we branch for 3.6 the two most recent versions of Visual Studio will probably be 2013 and 14, so we’re really only proposing moving forward a few months early.
Seeing the feature list seems compelling, but MSVC's actual support is
often still below the standard you can find in GCC or Clang, even in
officially supported features. There's a price to be paid not just in terms
of breaking users who are still VS2012-dependent, but also in terms of
debugging VS2013-only bugs.
Personally, I think that it's worth upping the minimum requirement whenever
you're not breaking a substantial portion of your userbase. All I'm saying
is, the experience of many of us using VS2013 is that that feature list is
a little ... optimistic. Upgrading on that basis alone may well yield
undesirable results.
I second this. My experience with VS is that new features are usually
broken if you go beyond the simple cases. And the roadmaps have little
credibility, based on a continuous flow of disappointments since...
forever.
Right now I'm on the process of switching to MinGW-w64. VS 2013 was a
no-no on terms of modern C++.
Is there any interest from Microsoft to actually fix those problems,
or is that their policy that what's there is there? The latter seems
to be their policy on other products, and for what I know, VS too. I
ask that because holding on partial and broken support that will never
be fixed or completed is kind of backwards.
I'm not a Windows guy, but I wonder why so many people use MSVC if the
support is so patchy and hopeless as most people seem to imply. Also,
compiling Clang with MSVC and making Clang MSVC compatible are two
completely different things. A commercial toolchain based on MSVC
compatibility doesn't necessarily need to be compiled with MSVC
itself.
Or maybe the Windows environment is so alien that I'm basing my points
on completely unreasonable assumptions...
MSVC survives because there’s no effective competition- it’s like communications providers in the United States or political parties in China. The alternatives like GCC have no decent development environments for them, and Clang has the bonus of not being mature w.r.t. things like Standard libraries. The reality is, there’s nowhere to go but MSVC. This stuff is the major reason why I’d positively love clang-cl. As soon as that is done, then support for cl can probably be entirely dropped and the state of the available compilers will be drastically improved.
Microsoft is issuing more and more out-of-band bugfix updates. But the current state for VS2013 is still that most bugfixes will hit in VS “14” (currently projected for 2015).
Visual C++ 2013 is not up to clang or gcc conformance level, but not that broken.
clang-cl would be great except it knows how to produce debug lines (codeview) but not full debug information (pdb files), so no real debugging. That’s a real showstopper.
That feature list is a hypothetical. Hypothetically, VS2012 CTP supported variadics, but they were unusably broken. I’ve yet to see how buggy it is. However, the fact that there have been three CTPs for VS “14” rather than just one does make me feel better about the chances.
Probably because it works for them. Company I work for is only interested in Windows and as such is happy to write code in any dialect of C++ that msvc supports, including extensions like “for each” loop, __super, abstract, etc.
Folks, this thread needs to stay focused on the technical question at hand.
This isn't a forum for complaining about the state of software development
tools at large or our attitudes toward them (complacent or otherwise).
The ‘technical question at hand’ is a case of whining about how Micro$lop tools are broken and that we should adjust our behavior to conform to their idiocy. I’m being extremely polite. If you want to use MSVC, fine. Go do so. But QUIT trying to turn LLVM into an MSVC replacement.
This email is not a particularly polite email. Goofy names do not make good
technical arguments.
There are a lot of users of LLVM and Clang. Some would like to use these
libraries on Windows in projects built with MSVC. The developers working on
these projects (I work mostly on LLVM these days, but used to hack on
Clang) decided that was a reasonable thing to support, and so we do. That
is the nature of an open source project.
There are also a lot of users that would like to use Clang as C++ compiler
on Windows. At least some of them would like to use it on their projects
currently built with MSVC. We decided to support them as well.
I'm not aware that we've stopped supporting other users by doing this, and
so I don't know why any of our users would object to this support becoming
available. So I don't think we've hurt our users in any way by pursuing
this, but feel free to file bugs if there are problems with Clang that are
impacting your use of it either as a collection of libraries or as a C++
compiler.
However, if you just want to influence the direction and strategy of the
open source project, you'll probably need to become a significant
contributor to it. Generally speaking, open source projects' direction are
determined by what direction the contributors want to take it.
Either way, I won't respond to this thread of discussion again. I encourage
you and everyone else to do the same. We should go back to discussing the
practical matter of what version of MSVC we support as a host compiler.
But it must. If you want to be able to use LLVM DLLs inside a Windows app, it has to be built with MSVC because they have their own C++ ABI. At some point, Clang will support Microsoft's ABI well enough to consider a bootstrap instead.
Also,
compiling Clang with MSVC and making Clang MSVC compatible are two
completely different things. A commercial toolchain based on MSVC
compatibility doesn't necessarily need to be compiled with MSVC
itself.
But it must. If you want to be able to use LLVM DLLs inside a Windows
app, it has to be built with MSVC because they have their own C++ ABI.
This is false. LLVM libraries can be used on C++ Windows applications
just fine without using MSVC at all.
At some point, Clang will support Microsoft's ABI well enough to
consider a bootstrap instead.
AFAIK Clang bootstraps on MinGW-w64.
To go back on topic: C++ features advertised by MSVC as recently
supported usually are too immature to be used on practice. So looking at
a brochure is not enough when deciding what you gain when you upgrade
your MSVC install.
“Why do developers make such ridiculous statements about broken tools?”
Richard, clang on Windows is not completely compatible with either mingw or Visual C++ toolchains so it’s not (yet! clang is improving all the time) a practical alternative.
clang TLS is not compatible with mingw implementation emutls, so no C++11 concurrency. (anyone know of a solution?)
clang does not produce debug information in Visual C++ format (except for line infromation), so no debugging.
I’m not sure is SEH support is ready in clang.
This leaves a C++ developer two main choices, the mingw toolchain or the Visual C++ one. I’m not choosing based on brouchures or blog posts. I do work with both toolchains extensively. My preference for development work is working around the C++ limitations of Visual C++ in exchange for developing under Visual Studio IDE which I find most productive.
YMMV, please, I’m not trying to start a flame war.
Ideally, I’d like to see clang completely support Visual C++ ABI and debugging info so we’ll have the best solution, clang with Visual Studio and integrated debugger.