-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fail to build when including json.hpp as a system include #1818
Comments
|
Sure thing! set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) and this is the full error I got:
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 |
I get the same issue with Clang/Clang++ 9.0.0 on Windows when compiling from the command line. EDIT: I compile with C++17 enabled |
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. |
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. 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: 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 |
I've got the same issue when including
|
@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 I have only managed to reproduce this with Windows |
@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 |
Any proposal how to proceed with this issue? |
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. |
My proposed hack works by replacing all These occur mostly on type traits like these: json/single_include/nlohmann/json.hpp Line 2725 in bccc8f0
|
I'm really hesitant to making this change as these operators are valid C++ and we even include the |
Same issue with clang-cl.exe on windows 10. |
same problem here... :'( |
Were you guys able to build the json library using Clang on Windows? I have the same issue.
|
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. |
@nlohmann 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... |
There is no special reason to use |
@nlohmann
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 Including
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. 😞 |
I tried to reproduce the issue with Clang 9 and got the following error:
(see https://github.com/nlohmann/json/runs/723346449?check_suite_focus=true). Clang version is:
Is this the same error? |
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. |
In the branch https://github.com/nlohmann/json/compare/clang_windows, I replaced all alternative operators ( |
Great, thanks, I will try it the first thing tomorrow! |
@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? |
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 |
I found a couple of more alternate operators on the clang-windows branch
but I also still get the same errors when compiling the tests. Edit: With the following hack the tests compile:
|
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. |
@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. |
@t-b Thanks for the info! I removed the remaining |
It works! I will open a PR for this! |
Great, I can't wait to test it next week! |
I'm not sure what you mean with
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. |
Sorry for confusion, I mean this: But I will test this manually, it should work if you removed all the alternative operators. 👍 |
@nlohmann Thanks for picking up! Just FYI I've used the clang tooling for MSVC with |
I also have no idea as I am not using Windows myself. I did not know about the |
@nlohmann The clang_windows branch passes debug tests here with |
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)? |
@t-b if it's merged with master, I can test on my infrastructure, it failed until now, because of this bug. |
I'll add a test. |
@tawmoto @Honeybunch Is the test I added in #2279 what you have in mind? |
@nlohmann |
Oki I tested from the |
Cool! I shall merge the test soon. |
Great, I can't wait for you to release the new version so I can integrate it! Thanks a lot! |
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.
Sample CMake script
Simple C++
Program compiles successfully
A ton of errors along the line of
error: expected '>'enable_if_t<is_detected<mapped_type_t, ConstructibleObjectType>::value and
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+
develop
branch?Version 3.6.1 and 3.7.0 release versions have the same problem
Nope
The text was updated successfully, but these errors were encountered: