Fail to build when including json.hpp as a system include #1818

Honeybunch · 2019-10-28T22:50:37Z

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

The text was updated successfully, but these errors were encountered:

nlohmann · 2019-10-29T07:33:12Z

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

Honeybunch · 2019-10-29T14:51:41Z

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 · 2019-11-01T09:33:15Z

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 · 2019-11-01T11:55:16Z

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 · 2019-11-12T18:32:18Z

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 · 2019-11-28T00:42:35Z

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 · 2019-11-28T13:16:52Z

@Rogiel Could you provide a MWE?

Rogiel · 2019-11-28T13:53:25Z

@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 · 2019-11-28T14:34:13Z

@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 · 2019-12-02T20:15:00Z

Any proposal how to proceed with this issue?

Honeybunch · 2019-12-02T21:44:40Z

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 · 2019-12-04T14:18:27Z

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:

json/single_include/nlohmann/json.hpp

Line 2725 in bccc8f0

enable_if_t<not std::is_same<ConstructibleArrayType,

nlohmann · 2019-12-16T16:13:24Z

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 · 2019-12-29T19:31:12Z

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 · 2020-01-05T13:29:50Z

same problem here... :'(

jabra11 · 2020-01-10T19:19:42Z

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 · 2020-02-09T19:36:49Z

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 · 2020-05-30T06:01:52Z

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 · 2020-05-30T10:57:16Z

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?

tawmoto · 2020-05-30T11:18:45Z

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 · 2020-05-30T17:00:05Z

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 · 2020-05-30T17:04:09Z

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 · 2020-06-03T19:28:15Z

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 · 2020-06-03T19:49:14Z

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 · 2020-06-04T08:40:01Z

@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 · 2020-06-04T08:42:34Z

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

t-b · 2020-07-10T23:37:37Z

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 · 2020-07-11T01:06:30Z

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 · 2020-07-11T08:08:24Z

@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 · 2020-07-11T11:41:14Z

@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 · 2020-07-11T12:00:52Z

It works! I will open a PR for this!

tawmoto · 2020-07-11T12:06:12Z

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 · 2020-07-11T12:13:26Z

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 · 2020-07-11T12:16:04Z

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 · 2020-07-11T12:26:35Z

@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 · 2020-07-11T12:29:33Z

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

t-b · 2020-07-11T12:47:19Z

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

t-b · 2020-07-16T17:50:05Z

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 · 2020-07-16T18:01:28Z

@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 · 2020-07-17T12:24:39Z

I'll add a test.

nlohmann · 2020-07-17T12:46:53Z

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

tawmoto · 2020-07-17T14:38:12Z

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

tawmoto · 2020-07-17T16:03:58Z

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

nlohmann · 2020-07-17T16:13:57Z

Cool! I shall merge the test soon.

tawmoto · 2020-07-17T16:27:38Z

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

Honeybunch added the kind: bug label Oct 28, 2019

stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Feb 9, 2020

stale bot closed this as completed Feb 16, 2020

nlohmann mentioned this issue May 30, 2020

Compilation failure using Clang on Windows #1898

Closed

nlohmann reopened this Jul 11, 2020

stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Jul 11, 2020

nlohmann added the solution: proposed fix a fix for the issue has been proposed and waits for confirmation label Jul 11, 2020

nlohmann self-assigned this Jul 11, 2020

nlohmann mentioned this issue Jul 11, 2020

Make library work with Clang on Windows #2259

Merged

nlohmann closed this as completed in #2259 Jul 12, 2020

nlohmann added this to the Release 3.8.1 milestone Jul 12, 2020

nlohmann added the release item: ⚡ improvement label Jul 12, 2020

nlohmann added a commit that referenced this issue Jul 17, 2020

✅ add test for target_include_directories #1818

2fd57d3

nlohmann mentioned this issue Jul 17, 2020

Add test for target_include_directories #2279

Merged

ax3l mentioned this issue Dec 3, 2020

Fix: Windows and/or includes (iso646) AMReX-Codes/amrex#1593

Merged

5 tasks

Fail to build when including json.hpp as a system include #1818

Fail to build when including json.hpp as a system include #1818

Comments

Honeybunch commented Oct 28, 2019 • edited Loading

nlohmann commented Oct 29, 2019

Honeybunch commented Oct 29, 2019

mathijs727 commented Nov 1, 2019 • edited Loading

t-b commented Nov 1, 2019

Honeybunch commented Nov 12, 2019 • edited Loading

Rogiel commented Nov 28, 2019

t-b commented Nov 28, 2019

Rogiel commented Nov 28, 2019

t-b commented Nov 28, 2019 • edited Loading

nlohmann commented Dec 2, 2019

Honeybunch commented Dec 2, 2019

Rogiel commented Dec 4, 2019

nlohmann commented Dec 16, 2019

StefanoLusardi commented Dec 29, 2019

Milerius commented Jan 5, 2020

jabra11 commented Jan 10, 2020 • edited Loading

stale bot commented Feb 9, 2020

tawmoto commented May 30, 2020 • edited Loading

nlohmann commented May 30, 2020

tawmoto commented May 30, 2020 • edited Loading

nlohmann commented May 30, 2020 • edited Loading

tawmoto commented May 30, 2020 • edited Loading

nlohmann commented Jun 3, 2020

tawmoto commented Jun 3, 2020

tawmoto commented Jun 4, 2020 • edited Loading

nlohmann commented Jun 4, 2020

t-b commented Jul 10, 2020 • edited Loading

t-b commented Jul 11, 2020

tawmoto commented Jul 11, 2020

nlohmann commented Jul 11, 2020

nlohmann commented Jul 11, 2020

tawmoto commented Jul 11, 2020 • edited Loading

nlohmann commented Jul 11, 2020

tawmoto commented Jul 11, 2020 • edited Loading

t-b commented Jul 11, 2020

nlohmann commented Jul 11, 2020

t-b commented Jul 11, 2020

t-b commented Jul 16, 2020

tawmoto commented Jul 16, 2020

nlohmann commented Jul 17, 2020

nlohmann commented Jul 17, 2020

tawmoto commented Jul 17, 2020 • edited Loading

tawmoto commented Jul 17, 2020

nlohmann commented Jul 17, 2020

tawmoto commented Jul 17, 2020

Honeybunch commented Oct 28, 2019 •

edited

Loading

mathijs727 commented Nov 1, 2019 •

edited

Loading

Honeybunch commented Nov 12, 2019 •

edited

Loading

t-b commented Nov 28, 2019 •

edited

Loading

jabra11 commented Jan 10, 2020 •

edited

Loading

tawmoto commented May 30, 2020 •

edited

Loading

tawmoto commented May 30, 2020 •

edited

Loading

nlohmann commented May 30, 2020 •

edited

Loading

tawmoto commented May 30, 2020 •

edited

Loading

tawmoto commented Jun 4, 2020 •

edited

Loading

t-b commented Jul 10, 2020 •

edited

Loading

tawmoto commented Jul 11, 2020 •

edited

Loading

tawmoto commented Jul 11, 2020 •

edited

Loading

tawmoto commented Jul 17, 2020 •

edited

Loading