fix(__any_allocator): add friend declaration so the cross-specialization converting constructor compiles - #2159
Open
deretame wants to merge 2 commits into
Open
Conversation
…ion converting constructor compiles on MSVC __any_allocator's converting constructor reads the private member of another specialization of the same class template, which the standard permits ([class.access], since C++17) but MSVC rejects with C2248. The conversion is instantiated whenever task_scheduler's type-erased backend copies an allocator on the heap-allocation fallback path (e.g. with an asio-based scheduler), so stdexec::task + asio + MSVC currently fails to compile. Add an explicit friend declaration (harmless on GCC/Clang) and a regression test that instantiates the converting constructor directly. Fixes NVIDIA#2158
…cted by GCC, Clang and MSVC alike The converting constructor of __any_allocator reads the private member of another specialization of the same template. That is rejected by all major compilers (MSVC C2248; Clang/GCC 'private member' error); upstream never noticed because the constructor is only instantiated on the heap-allocation fallback path of task_scheduler (large operation states, e.g. asio-based schedulers), which the upstream test matrix does not exercise. The friend declaration makes the conversion legal on every compiler.
deretame
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
stdexec::task_schedulerfails to compile when its type-erased backend takes the heap-allocation fallback path:__any_allocator<std::byte>has a converting constructor that reads the private member of another specialization of the same class template. That access is rejected by all major compilers (MSVCC2248, Clang and GCC report it as accessing a private member) — verified with MSVC cl 19.51.36252, clang-cl 22.1.8 and GCC 13.3.The constructor is only instantiated on the heap-allocation fallback path (operation state larger than
task_scheduler's inline storage), which the upstream test matrix never exercises — e.g.stdexec::taskon an asio-based scheduler (asio::post+use_sender). So the build breaks on every compiler, not just MSVC. See #2158 for the full analysis and repro.Fix
Add an explicit friend declaration to
__any_allocator(makes the cross-specialization access legal on every compiler):Test
Add
test/stdexec/detail/test_any_allocator.cpp, which instantiates the cross-specialization converting constructor directly. The test fails on every compiler without the friend declaration (verified: MSVC C2248, Clang private-member error, GCC private-within-this-context), so it guards the fix on all platforms.Verified locally on MSVC cl 19.51.36252:
__any_allocator<int>→__any_allocator<std::byte>conversiontest.stdexecfull build + run (*any_allocator*)clang-cl 22.1.8 also rejects the conversion without the friend declaration and compiles with it.
Fixes #2158