Proposal: Become C++11 code base, Remove Support for VS 2013 builds

[ianwjhalliday]

TL;DR: Remove VS 2013 support in ChakraCore so we can use the full C++11 feature set, following suit with the rest of the C++ community.

Proposal

Drop support for ChakraCore build using VS 2013 tools.

Require VS 2015 toolset.

Proposed Plan

Remove VS2013 support as part of v2.0 release of ChakraCore.

Maintain VS2013 support in v1.x release branches.

Impact

No impact on JSRT consumers since JSRT is a C API.

No impact on Nuget consumers since prebuilt binaries provided.

Impact users that build ChakraCore 2.0+ from source. Require them to upgrade their MSVC build toolset to minimum VS 2015.

Motivation

• MSVC in VS 2013 is not fully C++11 compliant
• Our minimum supported clang build on Linux and MacOS is fully C++11 compliant
• The C++ community has been moving to C++11 code for many years now
• Chakra developers wish to use C++11 features unavailable in VS2013, e.g. constexpr
  • e.g. Chakracore build break on VS2013 RC #309 cross-plat: wrap wchar type and string literal #456 Support for Visual Studio 2013 #1484 require min of VS2015 Update 3 for constexpr #1686

Supporting Motivation

Node.js has dropped VS2013 support in favor of using C++11 features. Node.js v6.8 (Oct 12 2016) and v7.x (upcoming) do not support VS2013, only VS2015.

• build: drop support for VS 2013 in v7 nodejs/node#7484
• build: drop support for VS 2013 in v6 LTS nodejs/node#7989 (comment)

ICU v58 (released Oct 24 2016) does not support VS2013, requires VS2015 or cygwin for Windows builds.

• http://site.icu-project.org/download/58

BlueJeans are not dependent on VS2013, they are using VS2015.3

• https://gitter.im/Microsoft/ChakraCore?at=58a4d329f045df0a2251e0dc

Users who wish to compile ChakraCore can easily do so with access to VS2015 MSVC toolset for free from the Microsoft Visual C++ Build Tools 2015

• https://blogs.msdn.microsoft.com/vcblog/2016/03/31/announcing-the-official-release-of-the-visual-c-build-tools-2015/

C++ 11/14/17 compiler support reference table

• http://en.cppreference.com/w/cpp/compiler_support

[dilijev]

I definitely support this.

FWIW, very little work is required on our part to follow this proposal. We already mainly use VS 2015 (dev14). We simply drop the dev12 part of the legacy configuration and switch to dev14 on Windows 7 for Legacy build & test. AFAIK, dev14 is already configured on the Win 7 CI machines. @mmitche can confirm.

Other things this would enable, although none are necessary to go forward with this:

• Dropping the _u macro for all unicode strings and use unicode string literals as supported by the standard for char16_t, i.e. u"..." instead of _u("...").
• Using constexpr in places where it may be helpful.

I'm sure there's more, but that's just off the top of my head.

[Cellule]

Same, I definitely support this!
More features and less work. From what I understand, the reason we kept it was to support some customers that still supported VS 2013, which from what you mentioned is not needed anymore.

[dilijev]

I opened a PR to master-ci to remove dev12 support from legacy (#2552) and a PR to update the Wiki (microsoft/ChakraCore-wiki#25). We can wait to merge them until there's consensus on this issue.

[obastemur]

I also support this but I would go for this after GCC support. Our Clang requirement (3.7+) is a pain on some of the distros and raising the compiler bar even more is something I would like to avoid.

[dilijev]

Is the default GCC in most distros not C++11 compliant?

[obastemur]

Is the default GCC in most distros not C++11 compliant?

It's not strictly about C++11 compliance (that is another issue though..)

It's more about introducing some new things and ending up with compiler bar is raised up even more.

[dilijev]

So basically you're saying that for now the VS 2013 support keeps us from raising the feature bar higher. Your concern is if we drop the support requirement, we could potentially move to using features that are supported in VS 2015 and Clang but not default versions of other toolchains like GCC?

How far away is GCC support?

[obastemur]

So basically you're saying that for now the VS 2013 support keeps us from raising the feature bar higher.

What I'm saying is, better don't change our codebase dramatically until ChakraCore compiles with GCC. I'm working on that update only on free time for now (around 30% is complete).. After 2.0 release period, I guess it will be a easier to estimate the process.

Not sure if we expect any tangible gain from dropping VS2013 sooner?

[dilijev]

@obastemur I agree we should wait until we have a successful build in GCC and CI support for the same.