[hmaarrfk]

Seems like there are other small patches necessary

claude

Draft. Follow-up to #117, which turned out to be only half of the fix.

What still fails

#117 fixed the friend class X::HashStateBase; declarations. With exactly those two lines applied, CUDA translation units on Windows that include an abseil hash container still fail under nvcc 13.4 + MSVC, now on the containers' base-class alias:

using Base = typename flat_hash_map::raw_hash_map;   // flat_hash_map.h(141) in 20260526.0

%BUILD_PREFIX%\Library\include\absl/container/flat_hash_map.h(141): error C2248: 'absl::lts_20260526::container_internal::raw_hash_map<T>::Hash': cannot access private typedef declared in class 'absl::lts_20260526::container_internal::raw_hash_map<T>'
%BUILD_PREFIX%\Library\include\absl/container/flat_hash_map.h(141): error C2248: 'absl::lts_20260526::container_internal::raw_hash_map<T>::Eq': cannot access private typedef declared in class 'absl::lts_20260526::container_internal::raw_hash_map<T>'

48 C2248 errors in total, none of the earlier C3856.

Evidence (all from conda-forge/onnxruntime-feedstock#183, win_64_cuda_compiler_version13.4python3.12)

abseil headers	result	log
unpatched libabseil 20260526.0 cxx17_h04e5de1_2	C3856 in hash.h and C2248 in flat_hash_map.h	https://github.com/conda-forge/onnxruntime-feedstock/actions/runs/35283211131/job/105409635861
+ the two lines from #117	C2248 only	https://github.com/conda-forge/onnxruntime-feedstock/actions/runs/37306309009/job/111750712123
+ this patch as well	builds and passes tests	https://github.com/conda-forge/onnxruntime-feedstock/actions/runs/37400676794/job/112067246126

Toolchain in all three: cuda-nvcc 13.4.92, vs2022_win-64 19.44.35207, C++20, abseil consumed as an installed package with ABSL_CONSUME_DLL. In those runs the patches are applied to the installed headers by the onnxruntime recipe, since it is pinned to 20260526.

Change

Patch 0005 spells the base type out in flat_hash_map, flat_hash_set, node_hash_map and node_hash_set, and renames their Hash/Eq template parameters to AbslHashT/AbslEqT:

-    class Hash =
+    class AbslHashT =
         typename container_internal::FlatHashMapPolicy<K, V>::DefaultHash,
-    class Eq = typename container_internal::FlatHashMapPolicy<K, V>::DefaultEq,
+    class AbslEqT =
+        typename container_internal::FlatHashMapPolicy<K, V>::DefaultEq,
 ...
-          absl::container_internal::FlatHashMapPolicy<K, V>, Hash, Eq,
+          absl::container_internal::FlatHashMapPolicy<K, V>, AbslHashT, AbslEqT,
           Allocator>::type {
-  using Base = typename flat_hash_map::raw_hash_map;
+  using Base = typename absl::container_internal::InstantiateRawHashMap<
+      absl::container_internal::FlatHashMapPolicy<K, V>, AbslHashT, AbslEqT,
+      Allocator>::type;

The rename is needed because raw_hash_map/raw_hash_set declare private typedefs named Hash, Eq and Alloc, which under MSVC hide template parameters of the same name inside the derived class body; without it the spelled-out base hits the same C2248. For the same reason node_hash_map and node_hash_set also get their Alloc parameter renamed to AbslAllocT (the flat containers call theirs Allocator, which does not collide).

Update: the first push of this PR missed the Alloc rename, which broke abseil's own win_64 and win_arm64 builds with node_hash_map.h(139): error C2248: 'raw_hash_map<T>::Alloc'. onnxruntime never instantiates the node containers, so its CI did not catch it. Fixed in 6e20276. The parameters are not used anywhere else in those class bodies. Header-only, no behaviour or ABI change (template parameter names are not mangled).

Build number bumped to 2.

Open points

• Not built locally. The patch was regenerated against the 20260817.0 source and checked to apply after 0004 (git apply --check and patch --dry-run). The CI evidence above is for the same change on the 20260526.0 headers.
• More invasive than Name HashStateBase explicitly so nvcc 13.4 can compile abseil's hash headers on Windows #117, and unlike Name HashStateBase explicitly so nvcc 13.4 can compile abseil's hash headers on Windows #117 it has no counterpart in onnxruntime's vendored-abseil patches and no upstream abseil report yet.
• Pinned version. As with Name HashStateBase explicitly so nvcc 13.4 can compile abseil's hash headers on Windows #117, this only reaches 20260817.0; consumers on the current global pin (libabseil 20260526) are not helped until a backport or the migration.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number
• Re-rendered (not needed: only the patch list and build number changed)

https://claude.ai/code/session_01XZa8BwzZpVJtREiCoVo1k6

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/37558789847. Examine the logs at this URL for more detail.}

[h-vetinari]

CI is failing here

[hmaarrfk]

thanks for the ping, hopefully it is fixed, i still need to review this, i kinda just skimmed it.

[hmaarrfk]

Thank you!

[h-vetinari]

I dislike distilling proper commit messages from claude's very verbose "drafts". In future PRs (this goes for all feedstocks I maintain, and I recommend it in general), please provide either:

• a clean git history with commit messages that have either been written, or at least heavily cleaned up, by a human
• the intended overall commit message (likewise human-distilled) prominently in the OP, updated to account for all changes, in case the commit history (likely) requires squashing¹

Footnotes

1. e.g. like here due to fixing up the patch a second time ↩

[hmaarrfk]

Thank you this is fair critcism, i'll work on that.

I think nobody likes to read somebody else's AI output.

[hmaarrfk]

I can't really promise to do that in "draft" mode, but once I mark things as "not draft" i'll give a once over to the commit history.