Fix x64 target platform for appveyor

[nickaein]

This pull request fixes #1374.

More details are explained in cmake documentation for Visual Studio 2015/2017

Note that the value of platform specified in appveyor.yml doesn't always match the target platform string required by cmake (e.g. x86 in appveyor.yml vs. cmake -A Win32). Therefore, we set the target platform for x64 directly in the generator name instead of passing the platform variable to cmake.

I've already run Appveyor on my fork to make sure this change is effective: https://ci.appveyor.com/project/nickaein/nlohmann-json/builds/21408703

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• Changes are described in the pull request, or an existing issue is referenced.
• The test suite compiles and runs without error.
• Code coverage is 100%. Test cases can be added by editing the test suite.
• The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header file single_include/nlohmann/json.hpp. The whole process is described here.

Please don't

• The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
• Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
• Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
• Please do not open pull requests that address multiple issues.

[nickaein]

CI job for Visual Studio 2017 x64 with flags /permissive- /std:c++latest /utf-8 is fails with a Stack overflow error on file test/data/json_testsuite/sample.json. There might be some bug in the test unit in handling this file. Any ideas?

[coveralls]

Coverage remained the same at 100.0% when pulling f164328 on nickaein:mydevel-appveyor-x64 into 676c847 on nlohmann:develop.

[nickaein]

After some digging, the issue seems to be caused by small stack size (1MB) on x64 platform on Windows. For demonstration, setting a higher stack size inside test/CMakeLists.txt fixes the issue:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /F2000000")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /STACK:2000000")

As default stack size is higher (usually 8MB) on Linux, the tests doesn't fail for Linux x64 builds.

It seems the root cause is the recursive implementation of write_ubjson which is susceptible to stackoverflow for deeply-nested JSON objects. Should write_ubjson be rewritten as non-recursive? Is there any other concerns (.e.g. performance)?

[nickaein]

@nlohmann What's your take on this? The PR fixes the build on x64 but the recursive implementation of write_ubjson causes stack overflow on Win x64 due to small default stack size on Win x64.

Will adding SAX parser eventually fix this issue? UBJSON seems to be covered in the proposal, but the implementation of write_ubjson in develop branch is still recursive.

[nlohmann]

The SAX parser has nothing to do with write_ubjson. The former reads JSON and is non-recursive. There is only nesting of containers like std::vector. The latter creates UBJSON values and, like the other serializers, is recursive as it traverses the JSON value. I would be happy to hear ideas on how to improve this situation, but this is unrelated to this issue.

I'd like not to change the CMakeLists.txt file, because this should be a detail for the user of the library to care about. If possible, the stack size should be adjusted in the AppVeyor configuration file so that the tests succeed. Is this something you can do, @nickaein ?

[nickaein]

Good idea! This should be doable, I will give it a try.

[nlohmann]

Looks good to me.

[nlohmann]

Thanks a lot!