fix build with -std=c++20#165
Conversation
| typedef typename value_alloc_type::pointer pointer; | ||
| typedef typename value_alloc_traits::difference_type difference_type; | ||
| typedef typename value_alloc_traits::size_type size_type; | ||
| typedef value_type& reference; |
There was a problem hiding this comment.
If it is possible in some crazy scenario for value_type to be void, then value_type& is not allowed. The solution would be to use typename std::add_reference<value_type>::type instead.
But if that scenario is not possible, then this PR is fine as-is.
There was a problem hiding this comment.
Going by https://en.cppreference.com/w/cpp/memory/allocator.html void has been removed at the same time as rebind.
So this seems fine?
There was a problem hiding this comment.
If value_type could be void then the existing code is wrong anyway, because std::allocator<void>::reference and std::allocator<void>::difference_type never existed. So if the code works today, it means value_type is never void. And so value_type& is valid.
There was a problem hiding this comment.
If it is possible in some crazy scenario for
value_typeto bevoid, thenvalue_type&is not allowed. The solution would be to usetypename std::add_reference<value_type>::typeinstead.
https://eel.is/c++draft/allocator.requirements#general-2.1 / https://eel.is/c++draft/allocator.requirements#general-11 require value_type to be a cv-unqualified object type, so it can't be void, or a reference, or a function.
…#118467) * fix(sparsehash): build with C++20 libstdc++ via allocator_traits gcc-16's libstdc++ defaults to C++20 and has dropped the long-deprecated std::allocator<>::rebind member. sparsehash 2.0.4's hashtable headers still reach for `Alloc::template rebind<V>::other`, so any translation unit that instantiates dense_hash_map/set now fails to compile. The package was being held on gcc-15 to sidestep this. Cherry-pick the upstream fix (sparsehash/sparsehash#165) onto the 2.0.4 tag. It moves the allocator handling to std::allocator_traits<Alloc> and rebind_alloc, which is the standard C++20 migration. Upstream is unmaintained (last release 2019, the PR has sat open since 2021), so we carry it through git-checkout's cherry-picks; the commit is reachable via the pull/165/head ref. With the headers fixed there is no longer any reason to pin the compiler, so drop gcc-15-default and let it build on the default toolchain. The functional test now compiles under both the default standard and C++20 to guard against a regression. * fix(py3-graph-tool): build on the default gcc-16 toolchain py3-graph-tool was pinned to gcc-15 to dodge two C++20 problems that gcc-16 surfaces by defaulting to that standard: - sparsehash's headers used the removed std::allocator<>::rebind (fixed separately in the sparsehash package); and - graph-tool's own src/graph/graph_io_binary.hh assigns a u8"" literal (a const char8_t* in C++20) to a const char*. The "gt_hash_set has no member named 'size'" errors in the bug report were a downstream symptom of the sparsehash header failing to instantiate, not a graph-tool problem. graph-tool 2.98 targets C++17 (configure.ac mandates it), so the right fix is to build it as C++17 rather than chase C++20 incompatibilities. Upstream did exactly this after 2.98 in commit db34b86 ("Fix compilation with recent GCC versions"), which prepends --std=gnu++17 to CXXFLAGS. Backport it via git-checkout's cherry-picks until a release carrying it is available. With the standard fixed, drop the gcc-15-default pin and the gcc-15 CC/CXX override so the package builds on the default toolchain. Link: OS-2197 Signed-off-by: Iain Lane <iain.lane@chainguard.dev> Export: 9104b34519cb5226c0daf6fb99980edb3ddaf43d
C++20 removed many deprecated
std::allocatormembers, causing sparsehash to fail when it is built with -std=c++20. This implements most of the uses of the removed members in terms ofstd::allocator_traits.There are no corresponding
referenceandconst_referencemembers instd::allocator_traits, in which case used the actualvalue_type&/const value_type&instead.