Bug 169769 – std::get for tuple should be declared before struct TupleHash is defined

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Web Template Framework

[Yoshiaki Jitsukawa]

As TupleHash::hash() refers to std::get(std::tuple), it should be declared beforehand. Otherwise clang's two phase lookup cannot resolve the proper function.

[Yoshiaki Jitsukawa]

Created attachment 304663 [details]
patch

[Yoshiaki Jitsukawa]

Created attachment 304664 [details]
patch

[Alex Christensen]

Comment on attachment 304664 [details]
patch

What file fails to compile without this?  We would ideally not add another #include to this widely-included file if we can get away with just including tuple before wtf/HashFunctions.h in the file that instantiates TupleHash

[Yoshiaki Jitsukawa]

JSClassRef.cpp, for example. Adding #include <tuple> to it works fine.

The completeness of HashFunctions.h doesn't matter?

[Yoshiaki Jitsukawa]

#include <utility>

template <typename T>
auto myget(const T& t)
{
	return std::get<0>(t);
}

#include <tuple>

int foo()
{
	return myget(std::tuple<int, int, int>(1, 2, 3));
}

---

Here's a simplified code which causes a compilation error with clang while MSVC is ok.

[Yoshiaki Jitsukawa]

There seems to be two factors in this issue:
 - <tuple> is implicitly included or not
 - compiler does two phase lookup or not

On mac and ubuntu, <tuple> is implicitly included in HashFunctions.h.

On windows, <tuple> is not included there but cl compiler doesn't do two phase lookup so webkit can build. However if we use clang-cl with "-fno-delayed-template-parsing", which enables two phase lookup, the compiler reports compilation errors of std::get(std::tuple), so there's still a problem of header inclusion.

Anyways, if toolchain supports, passing "-fdelayed-template-parsing" (not "-fno-delayed-template-parsing") can be a workaround.

[Don Olmstead]

*** This bug has been marked as a duplicate of bug 179926 ***

[Maciej Stachowiak]

Comment on attachment 304664 [details]
patch

Unflagging and obsoleting since this was resolved as a dupe.