Json: Fail to build when including json.hpp as a system include

[Honeybunch]

• What is the issue you have?

When including json.hpp if the include directory is marked as a system include (-isystem rather than -I) it will fail to build

I have to turn on CMAKE_NO_SYSTEM_FROM_IMPORTED and force the include path to be used as -I instead of -isystem. -isystem is used whenever nlohmann is provided as part of an imported CMake target. This happened to me due to using nlohmann from hunter with LLVM for Windows.

• Please describe the steps to reproduce the issue. Can you provide a small but working code example?

Sample CMake script

project(test)
cmake_minimum_required(VERSION 3.14)

add_executable(test main.cpp)
target_include_directories(test SYSTEM PRIVATE "<path/to/nlohmann/json>")

Simple C++

#include <nlohmann/json.hpp>

int main()
{
// Don't even have to call anything
return 0;
}

• What is the expected behavior?

Program compiles successfully

• And what is the actual behavior instead?

A ton of errors along the line of error: expected '>'enable_if_t<is_detected<mapped_type_t, ConstructibleObjectType>::value and

• Which compiler and operating system are you using? Is it a supported compiler?

Clang 9.0.0 but the same behavior occurs with 8.0.0/8.0.1

This is with LLVM for Windows and happens with the ClangCL toolset for VS2019 and the Ninja generator in CMake 3.15+

• Did you use a released version of the library or the version from the develop branch?

Version 3.6.1 and 3.7.0 release versions have the same problem

• If you experience a compilation error: can you compile and run the unit tests?

Nope

[nlohmann]

• Can you make sure you use C++11?
• Can you please post the complete error messages?

[Honeybunch]

Sure thing!
Made sure to enable C++11 in CMake:

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

and this is the full error I got:

C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE   -isystem C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd   -std=c++14 -MD -MT CMakeFiles/test.dir/main.cpp.obj -MF CMakeFiles\test.dir\main.cpp.obj.d -o CMakeFiles/test.dir/main.cpp.obj -c ../main.cpp
In file included from ../main.cpp:1:
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:950:28: error: expected '>'
           enable_if_t<not is_basic_json<T>::value>>
                           ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:950:28: error: missing 'typename' prior to dependent type name 'is_basic_json<T>::value'
           enable_if_t<not is_basic_json<T>::value>>
                           ^~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:950:52: error: expected unqualified-id                  enable_if_t<not is_basic_json<T>::value>>
                                                   ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:965:68: error: expected '>'
struct has_non_default_from_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                                   ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:965:68: error: missing 'typename' prior to dependent type name 'is_basic_json<T>::value'
struct has_non_default_from_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                                   ^~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:965:92: error: expected unqualified-id       struct has_non_default_from_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                                                           ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:980:54: error: expected '>'
struct has_to_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                     ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:980:54: error: missing 'typename' prior to dependent type name 'is_basic_json<T>::value'
struct has_to_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                     ^~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:980:78: error: expected unqualified-id       struct has_to_json<BasicJsonType, T, enable_if_t<not is_basic_json<T>::value>>
                                                                             ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1027:17: error: missing 'typename' prior to dependent type name 'is_detected<mapped_type_t, CompatibleObjectType>::value'
    enable_if_t<is_detected<mapped_type_t, CompatibleObjectType>::value and
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1027:73: error: expected '>'
    enable_if_t<is_detected<mapped_type_t, CompatibleObjectType>::value and
                                                                        ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1028:5: error: expected '>'
    is_detected<key_type_t, CompatibleObjectType>::value >>
    ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1052:17: error: missing 'typename' prior to dependent type name 'is_detected<mapped_type_t, ConstructibleObjectType>::value'
    enable_if_t<is_detected<mapped_type_t, ConstructibleObjectType>::value and
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1052:76: error: expected '>'
    enable_if_t<is_detected<mapped_type_t, ConstructibleObjectType>::value and
                                                                           ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1053:5: error: expected '>'
    is_detected<key_type_t, ConstructibleObjectType>::value >>
    ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1112:17: error: missing 'typename' prior to dependent type name 'is_detected<value_type_t, CompatibleArrayType>::value'
    enable_if_t<is_detected<value_type_t, CompatibleArrayType>::value and
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1112:71: error: expected '>'
    enable_if_t<is_detected<value_type_t, CompatibleArrayType>::value and
                                                                      ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1113:5: error: expected '>'
    is_detected<iterator_t, CompatibleArrayType>::value and
    ^
C:/.hunter/_Base/e98d3d3/409dae9/aaa0f28/Install/include\nlohmann/json.hpp:1142:21: error: expected '>'
    enable_if_t<not std::is_same<ConstructibleArrayType,
                    ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
ninja: build stopped: subcommand failed.

This happens with C++11, 14 and 17. Cmake seems to like to set -std=c++14 when I use C++11 but I confirmed that I get the same error if I manually invoke the compiler with -std=c++11.

Seems like clang isn't happy with the boolean alternative not, and etc. keywords in the templates? No idea why that may be.

[mathijs727]

I get the same issue with Clang/Clang++ 9.0.0 on Windows when compiling from the command line.
If I compile my (CMake) project with Clang-cl (8.0.0?) from within Visual Studio 2019 (version 16.3.6) everything is fine though.

EDIT: I compile with C++17 enabled

[t-b]

Can we come up with a MWE? I've tried with https://godbolt.org/z/Xk_JXm but that works in MSVC and clang on linux.

I've seen differences with the clang toolset compiler on windows compared to pure clang.

[Honeybunch]

Hey! Sorry for the late reply on this. I've just whipped up a MWE cmake project. Not sure how to do this sort of include pattern on godbolt.
test.zip

If you build with main.cpp including "bad.h" build will fail. If you include "good.h" instead it will work.

Here's bad.h:

#pragma once

#include <type_traits>
#include <iostream>
#include <ciso646>

template<bool B, typename T = void>
using enable_if_t = typename std::enable_if<B, T>::type;

template<typename T, typename = enable_if_t<std::is_pod<T>::value and std::is_trivial<T>::value>>
bool square(T param) {
    return param and param;
}

And good.h

#pragma once

#include <type_traits>
#include <iostream>

template<bool B, typename T = void>
using enable_if_t = typename std::enable_if<B, T>::type;

template<typename T, typename = enable_if_t<std::is_pod<T>::value && std::is_trivial<T>::value>>
bool square(T param) {
    return param && param;
}

Edit: Just to clarify with LLVM for Windows and Ninja installed I configure with:
cmake -GNinja -Bbuild
and build with
cmake --build build

This only fails with clang as MSVC does not have a "system" include concept

I haven't tested this on Linux or macos yet but I can if that would be helpful

[Rogiel]

I've got the same issue when including json.hpp in a precompiled header (now supported with the latest CMake 3.16.0). I have only tested with clang with the GNU command line style (i.e. not clang-cl).

$ clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

$ cmake --version
cmake version 3.16.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

[t-b]

@Rogiel Could you provide a MWE?

[Rogiel]

@Rogiel Could you provide a MWE?

Sure, here it is: https://github.com/Rogiel/nlohmann-json-pch-bug

If you comment out the hack at the end of CMakeLists.txt (that defines and, or and not to their respective operators) everything works fine but that is hacky and will 100% break on any non-toy example.

I have only managed to reproduce this with Windows clang++.exe (NOT clang-cl.exe).

[t-b]

@Rogiel Thanks for the quick reply. After some more digging I think this is the same as https://bugs.llvm.org/show_bug.cgi?id=42427.

So we probably need a cmake option to define and, or not so that users using that cmake with system include headers can work around that bug.

[nlohmann]

Any proposal how to proceed with this issue?

[Honeybunch]

I just did some digging on my linux box. I can confirm that this is isolated to Windows. GCC and Clang on Linux compile my MWE just fine with C++11. Reading that LLVM issue it sounds like this is an issue with clang's Windows support. Looks like there hasn't been any recent discussion related to why clang is acting this way but it appears intentional.

The easiest way to fix this would just be to remove all instances of the alternate identifiers.

[Rogiel]

Any proposal how to proceed with this issue?

My proposed hack works by replacing all and by && using a macro. A simply fix would be to replace and operators with && operators. Same should be done for or and not.

These occur mostly on type traits like these:

https://github.com/nlohmann/json/blob/bccc8f0577bf7a5a98d1a7f62adfddf3f43b8a3e/single_include/nlohmann/json.hpp#L2725

[nlohmann]

The easiest way to fix this would just be to remove all instances of the alternate identifiers.

I'm really hesitant to making this change as these operators are valid C++ and we even include the <ciso646> header which should convince noncompliant compilers about this...

[StefanoLusardi]

I have only managed to reproduce this with Windows clang++.exe (NOT clang-cl.exe).

Same issue with clang-cl.exe on windows 10.
The workaround suggested by @Rogiel works in this scenario too (of course this is still not applicable to real world cases).

[Milerius]

same problem here... :'(

[jabra98]

Were you guys able to build the json library using Clang on Windows? I have the same issue.
I'll use the workaround mentioned by @Rogiel for now.

#define and &&
#define or ||
#define not !

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tawmoto]

The easiest way to fix this would just be to remove all instances of the alternate identifiers.

I'm really hesitant to making this change as these operators are valid C++ and we even include the <ciso646> header which _should_ convince noncompliant compilers about this...

@nlohmann
I perfectly agree, but is there any reason to use and instead of &&? Is and the recommended way of doing this?
Aren't both correct? Sorry I am not familiar with complex template programming.

I am just a bit sad because we cannot use this library in our projects just because of this silly issue :(. It's fantastic easy to use and I love it...
Also clang for Windows is the default compiler for firefox and I think for chrome and the best C++ json library doesn't work with it...

[nlohmann]

There is no special reason to use and instead of &&. In any case, this is valid C++ (see https://en.cppreference.com/w/cpp/language/operator_alternative). Does https://github.com/nlohmann/json/issues/1818#issuecomment-573170240 work for you?

[tawmoto]

There is no special reason to use and instead of &&. In any case, this is valid C++ (see https://en.cppreference.com/w/cpp/language/operator_alternative). Does #1818 (comment) work for you?

@nlohmann
Thanks for answering and for your nice support, this code works but it's a bit hackish

#if defined(_WIN32) && defined(__clang__)
#    define and && // NOLINT
#    define or ||  // NOLINT
#    define not !  // NOLINT
#endif

#include "nlohmannjson/json.hpp"

#if defined(_WIN32) && defined(__clang__)
#    undef and // NOLINT
#    undef or  // NOLINT
#    undef not // NOLINT
#endif

Although I did not see it in many projects, I know that it's perfectly valid C++, but LLVM on Windows acts a bit strange....This is not the first time when a compiler doesn't respect the standard.

Currently I am using cJSON and I managed to convinge my colleagues to switch to this modern library (maybe you remember my first try), which I started to do, the code looks beautiful compared to cJSON and I am frustrated(on LLVM, not on you!), because now I have to revert back to cJSON, becauses solely on this issue.

I think the correct solution is to have those defined in the json.hpp, but, if clang on windows is not supported, I guess you don't have any plans to add those...

Including <ciso646> does not help unfortunetaly, because those defines are not there, they are only for C language, not C++.

The same words are defined in the C programming language in the include file <iso646.h> as macros. Because in C++ these are built into the language, the C++ version of <iso646.h>, as well as <ciso646>, does not define anything.

Again, thank you for your great support, as I said before, I feel a bit sad because a silly LLVM problem causes so much trouble and I am stuck with cJSON. 😞

[nlohmann]

I tried to reproduce the issue with Clang 9 and got the following error:

In file included from D:\a\json\json\test\src\unit-regression.cpp:37:
D:/a/json/json/single_include\nlohmann/json.hpp:12624:56: error: expected '>'
                    if (j.m_value.number_unsigned < 128)
                                                       ^

(see https://github.com/nlohmann/json/runs/723346449?check_suite_focus=true).

Clang version is:

clang version 9.0.0 (tags/RELEASE_900/final); Target: x86_64-pc-windows-msvc; Thread model: posix

Is this the same error?

[tawmoto]

The error is the same but we got it in the templates, not in simple ifs clauses, exactly like OP. Also we include json.hpp as a SYSTEM header in cmake.
Btw, I think that we can create a thin wrapper over it, having those define/undef at the moment.. hopefully it can be "fixed" in the future...thanks Niels

[nlohmann]

In the branch https://github.com/nlohmann/json/compare/clang_windows, I replaced all alternative operators (and, or, not), but still get the same error, see https://github.com/nlohmann/json/runs/735950025?check_suite_focus=true. Either I missed an operator, or there is a different reason.

[tawmoto]

In the branch https://github.com/nlohmann/json/compare/clang_windows, I replaced all alternative operators (and, or, not), but still get the same error, see https://github.com/nlohmann/json/runs/735950025?check_suite_focus=true. Either I missed an operator, or there is a different reason.

Great, thanks, I will try it the first thing tomorrow!

[tawmoto]

@nlohmann Works like a charm!! thanks a lot!

Your changes are correct, I am not sure why it does not compile on the github clang...

Any chance that it will be released in one of the future versions?
Becasue this clearly fixes this "issue". (1818)

[nlohmann]

Good to know that it works. But I really would like to have a working CI such that we do not break this in the future.

I'm using this version: clang version 9.0.0 (tags/RELEASE_900/final); Target: x86_64-pc-windows-msvc

[tawmoto]

I perfectly understand and I agree, I will try to investigate and give you more details if needed.
We are using also clang 9.

[nlohmann]

More details would be awesome! I will try to also compile with Clang 8.

[nlohmann]

Got the same error with Clang 10, and some compatibility error with Clang 8. I really do not know what's going on there.

Out of curiosity: can you compile the test suite?

[tawmoto]

Unfortunately I don't have the clang setup on my PC (I am using linux), it's on a remote PC build machine with special rights.
I hope today or tomorrow I can replicate it on my PC and try to replicate. :+1:

[tawmoto]

Btw, Niels, I don't see this fix dependant on the clang compilation (#1898, also to have the clang CI working), it's just reverting from the alternative operands to "normal" ones.

So it fixes one bug (the current one), but not the entire clang windows compilation :-)
The important thing is not to break anything on other platforms.

As I said, I will try to replicate these days. :+1:

[tawmoto]

Hi again, I tried it with clang and vstudio, I can tell you that on vstudio I get 2 errors on unit tests compilation.
Also with clang, the error is not on the line that CI provided, but a different one.

SECTION("issue #144 - implicit assignment to std::string fails")
    {
        json o = {{"name", "value"}};

        std::string s1 = o["name"];
        CHECK(s1 == "value");

        std::string s2;
        s2 = o["name"];

        CHECK(s2 == "value");
    }

../test/src/unit-regression.cpp:463:12: error: use of overloaded operator '=' is ambiguous (with operand types 'std::string' (aka 'basic_string<char, char_traits<char>, allocator<char> >') and 'nlohmann::basic_json<std::map, std::vector, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, adl_serializer>::value_type' (aka 'nlohmann::basic_json<std::map, std::vector, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, adl_serializer>'))
        s2 = o["name"];
        ~~ ^ ~~~~~~~~~

I commented that unit test from cmake and I got another one then

In file included from ../test/src/unit-conversions.cpp:33:
In file included from ../single_include\nlohmann/json.hpp:37:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\algorithm:11:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\xmemory:16:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\xutility:3778:16: error: use of overloaded operator '=' is ambiguous (with operand types 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >' and 'const nlohmann::basic_json<std::map, std::vector, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, adl_serializer>')
        *_Dest = *_First;
        ~~~~~~ ^ ~~~~~~~
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\xutility:3814:26: note: in instantiation of function template specialization 'std::_Copy_unchecked<nlohmann::detail::iter_impl<const nlohmann::basic_json<std::map, std::vector, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, adl_serializer> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > *>' requested here
    _Seek_wrapped(_Dest, _Copy_unchecked(_UFirst, _ULast, _UDest));

And with VStudio I get the same problem.

[tawmoto]

I think this time it doesn't have anything to do with the alternate operands, I am pretty sure that clang on Windows is a lot more restrictive than gcc or vstudio (which I can confirm, because we compile our projects with many compilers) and the unit tests just push C++ to the limit in a non-conformant way.

It does not happen to the rest of us is because we don't use those ambigous operators like the unit tests are doing. And also we don't compile unit tests. :-)
So the library works perfectly on any platform, the unit tests do not.

Look, Visual Studio(not related to clang!) also complains about many of the problems in unit tests, see the red coloring.

In the last picture the unit tests assigns a json object to an int... should this work?

[tawmoto]

Hope this helps, sorry for repeating myself but I see this as 2 separate tasks:

• fix the current problem (which you did in the clang-windows branch, thank you for that again)
• make json library (in fact unit tests) compliant with clang on Windows, which is a different story. The library is perfect, but unit tests have to be modified, because clang is more restrictive.

[nlohmann]

• Visual Studio does not use the same parser for syntax highlighting/warning as it uses for compilation. As such, I had several bug reports that code that does compile was full of red lines in the MSVC editor.
• The unit tests do compile with MSVC 15, 17, and 19. If you experience any problems, please open an issue.
• The conversion to an int is valid - the library implements several implicit conversion operators.

I am hesitant of merging the clang-windows branch, because the change of the operator style did not fix the problem. Furthermore, I do not understand the remaining compilation error.

[tawmoto]

I am hesitant of merging the clang-windows branch, because the change of the operator style did not fix the problem

I see, but I don't understand why we can compile perfectly our projects with json.hpp using clang on Windows (on clang-windows branch) and the problem happens only on unit tests...very strange

[t-b]

I found a couple of more alternate operators on the clang-windows branch

$ git diff ..
diff --git a/single_include/nlohmann/json.hpp b/single_include/nlohmann/json.hpp
index a387655f..e0652628 100644
--- a/single_include/nlohmann/json.hpp
+++ b/single_include/nlohmann/json.hpp
@@ -4688,7 +4688,7 @@ struct wide_string_input_helper<BaseInputAdapter, 2>
             }
             else
             {
-                if (JSON_HEDLEY_UNLIKELY(not input.empty()))
+                if (JSON_HEDLEY_UNLIKELY(!input.empty()))
                 {
                     const auto wc2 = static_cast<unsigned int>(input.get_character());
                     const auto charcode = 0x10000u + (((static_cast<unsigned int>(wc) & 0x3FFu) << 10u) | (wc2 & 0x3FFu));
@@ -4832,7 +4832,7 @@ using contiguous_bytes_input_adapter = decltype(input_adapter(std::declval<const
 template < typename CharT,
            typename std::enable_if <
                std::is_pointer<CharT>::value&&
-               not std::is_array<CharT>::value&&
+               !std::is_array<CharT>::value&&
                std::is_integral<typename std::remove_pointer<CharT>::type>::value&&
                sizeof(typename std::remove_pointer<CharT>::type) == 1,
                int >::type = 0 >
@@ -9584,7 +9584,7 @@ scan_number_done:
         // ignore comments
         if (ignore_comments && current == '/')
         {
-            if (not scan_comment())
+            if (!scan_comment())
             {
                 return token_type::parse_error;
             }

but I also still get the same errors when compiling the tests.

Edit:

With the following hack the tests compile:

diff --git a/test/src/unit-regression.cpp b/test/src/unit-regression.cpp
index 655d8dd3..2c739678 100644
--- a/test/src/unit-regression.cpp
+++ b/test/src/unit-regression.cpp
@@ -1965,9 +1965,9 @@ TEST_CASE("regression tests, exceptions dependent")
 /////////////////////////////////////////////////////////////////////
 // for #1642
 /////////////////////////////////////////////////////////////////////
-template <typename T> class array {};
-template <typename T> class object {};
-template <typename T> class string {};
-template <typename T> class number_integer {};
-template <typename T> class number_unsigned {};
-template <typename T> class number_float {};
+//template <typename T> class array {};
+//template <typename T> class object {};
+//template <typename T> class string {};
+//template <typename T> class number_integer {};
+//template <typename T> class number_unsigned {};
+//template <typename T> class number_float {};

[t-b]

The branch https://github.com/t-b/json/pull/new/get-clang-with-msvc-working does compile here. It only comments out the template specializations and does not remove alternate operator syntax.

[tawmoto]

@t-b thanks a lot for your modifications and testing, but alternate operators should be replaced also in order to include the header as SYSTEM, which most of us do, to except the library from compiler warnings or clang-tidy.

[nlohmann]

@t-b Thanks for the info! I removed the remaining nots from https://github.com/nlohmann/json/tree/clang_windows. I will try the fix for the regression tests next. Would be cool to finally get the library to work with Clang for Windows!

[nlohmann]

It works! I will open a PR for this!

[tawmoto]

It works! I will open a PR for this!

Great, I can't wait to test it next week!
Is there an automatic test on your side that tests this particular scenario (with clang on Windows + include as SYSTEM?
Thanks Niels.

[nlohmann]

I'm not sure what you mean with

Windows + include as SYSTEM

There is now a CI step to compile the library with Clang 9 and 10 on Windows (https://github.com/nlohmann/json/pull/2259/checks?check_run_id=860838624). See https://github.com/nlohmann/json/blob/clang_windows/.github/workflows/windows_clang.yml for more information.

[tawmoto]

I'm not sure what you mean with

Windows + include as SYSTEM

Sorry for confusion, I mean this:
target_include_directories(test SYSTEM PRIVATE "<path/to/nlohmann/json>")
This was in fact the problem that the OP mentioned in the first post.

But I will test this manually, it should work if you removed all the alternative operators. 👍
Thank you a lot again for all your support, Niels.

[t-b]

@nlohmann Thanks for picking up!

Just FYI I've used the clang tooling for MSVC with cmake -G "Visual Studio 16 2019" -T "ClangCL" .. I don't know if that is the same as plain LLVM/clang on Windows.

[nlohmann]

I also have no idea as I am not using Windows myself. I did not know about the -T "ClangCL" parameter either.

[t-b]

@nlohmann The clang_windows branch passes debug tests here with -T "ClangCL".

[t-b]

We now have Clang on Windows tested for CI. Maybe someone here can provide a testcase for the SYSTEM include folder issue so we can verify that this works now (and stays fixed)?

[tawmoto]

@t-b if it's merged with master, I can test on my infrastructure, it failed until now, because of this bug.
I guess the OP's small sample should do the job, also.

[nlohmann]

I'll add a test.

[nlohmann]

@tawmoto @Honeybunch Is the test I added in #2279 what you have in mind?

[tawmoto]

@nlohmann
Yes, the test seems ok, I will give it a try on my infrastructure ASAP.
I see that is merged with master :+1:

[tawmoto]

Oki I tested from the develop branch, everything is green, great!

[nlohmann]

Cool! I shall merge the test soon.

[tawmoto]

Great, I can't wait for you to release the new version so I can integrate it! Thanks a lot!