Skip to content
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

Fails to compile when std::iterator_traits is not SFINAE friendly. #1341

Closed
dgavedissian opened this issue Nov 7, 2018 · 3 comments
Closed

Comments

@dgavedissian
Copy link
Contributor

dgavedissian commented Nov 7, 2018

  • What is the issue you have?

I'm trying to use this library as part of another project which is in the process of being ported to an esoteric platform (PS4). This platform fully supports C++11 and uses clang 5, but they have their own implementation of the STL. This STL implementation implements std::iterator_traits<T> in such a way that it can't be used with SFINAE when T is not an iterator type. This then causes a compiler error when trying to create an instance of nlohmann::json and in many other places.

Due to the nature of this being a compiler which is under an NDA, it's not easy for others to reproduce it unless another compiler can be found with a std::iterator_traits that has a similar limitation.

I've already fixed this by implementing a custom nlohmann::details::iterator_traits inside nlohmann/detail/iterators/iterator_traits.hpp and made everything use that instead to detect whether a type is an iterator (similar to how std::index_sequence and std::detected is implemented inline already). Will open a PR momentarily.

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

The following code snippet fails to compile:

#include <nlohmann/detail/meta/type_traits.hpp>

using namespace nlohmann::detail;

int main() {
  static_assert(is_detected<value_type_t, std::iterator_traits<std::string>>::value == false, "!!!");
}

(however, replacing std::string with std::vector<std::string>::iterator works fine).

  • What is the expected behavior?
    Successfully compile.

  • And what is the actual behavior instead?

C:\Program Files (x86)\SCE\ORBIS SDKs\5.500\host_tools\lib\clang\../../../target/include\xutility:432:26: error: no type named 'iterator_category' in 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >'
        typedef typename _Iter::iterator_category iterator_category;
                ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
external/nlohmann_json\nlohmann/detail/meta/type_traits.hpp:55:1: note: in instantiation of template class 'std::iterator_traits<std::string>' requested here
using value_type_t = typename T::value_type;
^
external/nlohmann_json\nlohmann/detail/meta/detected.hpp:31:33: note: in instantiation of template type alias 'value_type_t' requested here
struct detector<Default, void_t<Op<Args...>>, Op, Args...>
                                ^
external/nlohmann_json\nlohmann/detail/meta/detected.hpp:38:1: note: during template argument deduction for class template partial specialization 'detector<Default, void_t<Op<Args...> >, Op, Args...>' [with Default = nlohmann::detail::nonesuch, Op = value_type_t, Args = <std::iterator_traits<std::string>>]
using is_detected = typename detector<nonesuch, void, Op, Args...>::value_t;
^
external/nlohmann_json\nlohmann/detail/meta/detected.hpp:38:1: note: in instantiation of template class 'nlohmann::detail::detector<nlohmann::detail::nonesuch, void, value_type_t, std::iterator_traits<std::string> >' requested here
test.cc:6:17: note: in instantiation of template type alias 'is_detected' requested here
  static_assert(is_detected<value_type_t, std::iterator_traits<std::string>>::value == false, "!!!");
  • Which compiler and operating system are you using? Is it a supported compiler?
    Clang 5.0.1 (PS4 version). It's not a supported compiler.

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

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

@nlohmann
Copy link
Owner

nlohmann commented Nov 8, 2018

Thanks for reporting and opening a PR! I shall have a look.

@stale
Copy link

stale bot commented Dec 8, 2018

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.

@stale 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 Dec 8, 2018
@nlohmann
Copy link
Owner

nlohmann commented Dec 8, 2018

There are still requested changes at #1342.

@stale 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 Dec 8, 2018
@nlohmann nlohmann added this to the Release 3.5.0 milestone Dec 20, 2018
@nlohmann nlohmann self-assigned this Dec 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants