[FR]: Trying to use std::filesystem::path as a type for testing::TestWithParam results in an endless recursion.

[b068931]

Does the feature exist in the most recent commit?

Either I didn't look hard enough or it does not exist in the most recent commit. At least, the version that Visual Studio uses has this problem. I looked in "gtest-printers.h".

Why do we need this feature?

Google Test supports C++17 as far as I understand. And std::filesystem::path is a type which can theoretically be used for tests against different files, so I would expect it work properly or fail with a meaningful message.

Describe the proposal.

The code gets stuck in a loop: UniversalPrint -> UniversalPrinter -> PrintTo -> DefaultPrintTo -> UniversalPrint until a stackoverflow occurs. It appears that this happens due to the fact that std::filesystem::path gets "printed" as an STL-like container (it has begin and end methods). However, this is the only "container" that I know of that returns itself when you dereference its iterator. This is exactly what results in an endless recursion.

Essentially, if you are trying to print "C:\Users\b068931" as a path, you will be stuck trying to print "C:". Dereferencing begin iterator returned by path "C:" will also return "C:".

I assume that this can be fixed by providing a template specialization for PrintTo function template. Which I could do, but I believe that it should already be included so as to avoid this strange crash.

Is the feature specific to an operating system, compiler, or build system version?

I have checked cppreference to ensure that this is not a Visual Studio's quirk, however they simply list the value that is returned by begin() as "iterator" without further specifying what it should return when dereferenced. I mainly use Visual Studio, so I am not sure how this works on other IDE's or OSes.

[brandl-muc]

Weird, there was a similar bug opened almost 10 years ago:
Infinite Loop when calling a mock function that takes boost::filesystem::path as parameter
The bug was completed in 2018, so this is probably a regression.

[b068931]

Thank you for pointing that out! But I do not really think that this is a regression, but rather a Visual Studio quirk after all. It seems that Visual Studio uses Google Test v1.8.x when you create a "Google Test" project. And this version contains the following buggy code snippet:

template<typename T>
struct VoidT {
    typedef void value_type;
};

template <typename T, typename = void>
struct HasValueType : false_type {};
template <typename T>
struct HasValueType<T, VoidT<typename T::value_type> > : true_type {
};

template <typename C,
          bool = sizeof(IsContainerTest<C>(0)) == sizeof(IsContainer),
          bool = HasValueType<C>::value>
struct IsRecursiveContainerImpl;

template <typename C, bool HV>
struct IsRecursiveContainerImpl<C, false, HV> : public false_type {};

// Since the IsRecursiveContainerImpl depends on the IsContainerTest we need to
// obey the same inconsistencies as the IsContainerTest, namely check if
// something is a container is relying on only const_iterator in C++11 and
// is relying on both const_iterator and iterator otherwise
template <typename C>
struct IsRecursiveContainerImpl<C, true, false> : public false_type {};

template <typename C>
struct IsRecursiveContainerImpl<C, true, true> {
  #if GTEST_LANG_CXX11
  typedef typename IteratorTraits<typename C::const_iterator>::value_type
      value_type;
#else
  typedef typename IteratorTraits<typename C::iterator>::value_type value_type;
#endif
  typedef is_same<value_type, C> type;
};

// IsRecursiveContainer<Type> is a unary compile-time predicate that
// evaluates whether C is a recursive container type. A recursive container
// type is a container type whose value_type is equal to the container type
// itself. An example for a recursive container type is
// boost::filesystem::path, whose iterator has a value_type that is equal to
// boost::filesystem::path.
template <typename C>
struct IsRecursiveContainer : public IsRecursiveContainerImpl<C>::type {};

Where the line "struct HasValueType<T, VoidT > : true_type" should have been "struct HasValueType<T, typename VoidT::value_type > : true_type" for SFINAE to work properly. Because of that HasValueType always evaluates to false, which, in turn, causes IsRecursiveContainer to always evaluate to false. So gtest thinks that std::filesystem::path is container but not a recursive one.

I have checked the branch for that version and it seems that it is no longer maintained. Moreover, other versions do not have this HasValueType trait because it was fixed by pool request #2002 (appeared just a few month later after v1.8.x stopped being maintained). So I don't think that there is a reason to keep this issue open.