[Doc] Drop MSVC2013 support

[mehdi_amini]

Summary

This is only updating the documentation. We'll be able to
update the codebase piece by piece.

[jlebar]

:happy dance:

docs/CodingStandards.rst

136

Can we add a comment or something to the effect of "should we reconsider this now that msvc 2013 is gone?"

[mehdi_amini]

docs/CodingStandards.rst

136

Maybe we should consider it now?

[jlebar]

docs/CodingStandards.rst

136

For my part, I have no problem with braced initializers inside a class. They can be helpful. But where possible I prefer using an equals sign, int foo_member = 42, because that's just easier to understand.

I dunno if that's contentious, though.

[rengolin]

I was looking at these files for gcc and clang, and I think we should eliminate all redundancies. You can talk about the features, but we shouldn't mention versions except in the "supported version" section.

I've removed the mention from the developer policy, pointing to the getting started because there was more involved description there, but I really think that's the wrong place, too. Though, this can be done in a separate patch.

Cheers,
Renato

[Hahnfeld]

docs/GettingStartedVS.rst

51

I don't think the CMake version is still valid here?

[Prazek]

yey!

docs/CodingStandards.rst

136

I also prefer = everywhere.

[kparzysz]

docs/CodingStandards.rst

136

If MSVC was the only reason that braced initializers were disallowed then we should allow them now. Why keep that restriction after MSVC is upgraded?

[Meinersbur]

Version increase in cmake/modules/CheckCompilerVersion.cmake is missing.

The reported version of Visual Studio 2015 Update 3 (the most recent) is 19.00.24215.1

[mehdi_amini]

docs/CodingStandards.rst

136

Note: the braced initializers policy is described somewhere else: http://llvm.org/docs/CodingStandards.html#do-not-use-braced-initializer-lists-to-call-a-constructor

I guess it is loosely related to the issue above, but not that much. My understanding is that the rule above forbid:

class X {
  std::string Name = "<uninitialized>";
}

I don't know the motivation for it though.

[rengolin]

This comment was removed by rengolin.

[mehdi_amini]

In D25710#573020, @Meinersbur wrote:

Version increase in cmake/modules/CheckCompilerVersion.cmake is missing.

The reported version of Visual Studio 2015 Update 3 (the most recent) is 19.00.24215.1

Good point.
Should we require the most recent update?

[zturner]

I don't know about requiring "the most recent update". But "Update 3", yes. There are some bad codegen issues in prior updates. But the wording should still say "Update 3" and not "the most recent update", because we don't want to accidentally have to bump the version in the unlikely event that an Update 4 were released, for example.

[mehdi_amini]

Update CheckCompilerVersion.cmake as well

[mehdi_amini]

Require update 3 and not the "latest" update.

[chandlerc]

(And fwiw, YAY THANK YOU ALL)

docs/CodingStandards.rst

136

I have no idea what the motivation here was...

I am very happy with non-static class member initializers *if and only if the equals is used*.

I have fairly strong objections to using braced initialization *syntax* here. But that is just about the syntax, which this comment doesn't really mention. I would just change this to say something along the lines of:

* Feel free to use these wherever they make sense and where the `=`
  syntax is allowed. Don't use braced initialization syntax.

(and link that last bit however the links work in RST)

[jmolloy]

In D25710#573851, @chandlerc wrote:

(And fwiw, YAY THANK YOU ALL)

Can we please get a rationale added for avoiding braced syntax? Not that I disagree with it, I just think things like that should be backed up in the document that bans them.

[chandlerc]

In D25710#573856, @jmolloy wrote:

In D25710#573851, @chandlerc wrote:

(And fwiw, YAY THANK YOU ALL)

Can we please get a rationale added for avoiding braced syntax? Not that I disagree with it, I just think things like that should be backed up in the document that bans them.

Yea, the current wording is a bit hand-wavy. I'll send out a separate patch that spiffs up the content to make this more clear.

[mehdi_amini]

Use Chandler wording:

Feel free to use these wherever they make sense and where the `=`
syntax is allowed. Don't use braced initialization syntax.

[rnk]

looks good, but you will need to rebase, I already landed a wording update. :)

docs/GettingStartedVS.rst

48

I kind of preferred the "latest update" wording. We don't say GCC 4.8.N, we say we support GCC 4.8, and some of those micro releases might have bugs, so make sure you're not using a buggy compiler. That's not to say that MSVC 2015 Update 1 won't work, it just isn't "supported".

[Prazek]

Why it is not yet in the master?

[mehdi_amini]

Didn't take time to rebase, feel free to take over.

docs/CodingStandards.rst

* But ``{}`` are required around inner ``do {} while()`` loops.  As a result,
     ``{}`` are required around function-like macros inside range-based for
     loops.
 
 * ``override`` and ``final``: N2928_, N3206_, N3272_
 * Atomic operations and the C++11 memory model: N2429_
 * Variadic templates: N2242_
 * Explicit conversion operators: N2437_
 * Defaulted and deleted functions: N2346_
-
-  * But not defaulted move constructors or move assignment operators, MSVC 2013
-    cannot synthesize them.
 * Initializer lists: N2627_
 * Delegating constructors: N1986_
 * Default member initializers (non-static data member initializers): N2756_
 
   * Only use these for scalar members that would otherwise be left
     uninitialized. Non-scalar members generally have appropriate default
-    constructors, and MSVC 2013 has problems when braced initializer lists are
-    involved.
+    constructors.
 
 .. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
 .. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
 .. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
 .. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
 .. _N1737: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf
 .. _N2541: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm
 .. _N2927: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf

docs/GettingStarted.rst

 require a modern host C++ toolchain, both compiler and standard library, in
 order to build LLVM.
 
 For the most popular host toolchains we check for specific minimum versions in
 our build systems:
 
 * Clang 3.1
 * GCC 4.7
-* Visual Studio 2013
+* Visual Studio 2015
 
 Anything older than these toolchains *may* work, but will require forcing the
 build system with a special option and is not really a supported host platform.
 Also note that older versions of these compilers have often crashed or
 miscompiled LLVM.
 
 For less widely used host toolchains such as ICC or xlC, be aware that a very
 recent version may be required to support all of the C++ features used in LLVM.

 causes Clang to refuse to compile condition_variable header file.  At the time
 of writing, this breaks LLD build.
 
 Getting a Modern Host C++ Toolchain
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This section mostly applies to Linux and older BSDs. On Mac OS X, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
-do. On Windows, just use Visual Studio 2013 as the host compiler, it is
+do. On Windows, just use Visual Studio 2015 as the host compiler, it is
 explicitly supported and widely available. FreeBSD 10.0 and newer have a modern
 Clang as the system compiler.
 
 However, some Linux distributions and some other or older BSDs sometimes have
 extremely old versions of GCC. These steps attempt to help you upgrade you
 compiler even on such a system. However, if at all possible, we encourage you
 to use a recent version of a distribution with a modern system compiler that
 meets these requirements. Note that it is tempting to to install a prior

docs/GettingStartedVS.rst

 Requirements
 ============
 Before you begin to use the LLVM system, review the requirements given
 below.  This may save you some trouble by knowing ahead of time what hardware
 and software you will need.
 
 Hardware
 --------
-Any system that can adequately run Visual Studio 2013 is fine. The LLVM
+Any system that can adequately run Visual Studio 2015 is fine. The LLVM
 source tree and object files, libraries and executables will consume
 approximately 3GB.
 
 Software
 --------
-You will need Visual Studio 2013 or higher, with the latest Update installed. 
+You will need Visual Studio 2015 or higher, with the latest Update installed. 
 
 You will also need the `CMake <http://www.cmake.org/>`_ build system since it
 generates the project files you will use to build with. CMake 2.8.12.2 is the
 minimum required version for building with Visual Studio, though the latest
 version of CMake is recommended.
 
 If you would like to run the LLVM tests you will need `Python
 <http://www.python.org/>`_. Version 2.7 and newer are known to work. You will
 need `GnuWin32 <http://gnuwin32.sourceforge.net/>`_ tools, too.
 
 Do not install the LLVM directory tree into a path containing spaces (e.g.