- changed milestone to 2020.3.0 release
Redundant completion handler type breaks compile
In the implementation, if two completion handlers with the same type occur in the same handler set (as built via operator|
) then compilation fails complaining about "ambiguous base class" deep in our template code.
To reproduce:
#include <upcxx/upcxx.hpp>
#include "../util.hpp"
using namespace std;
int main() {
upcxx::init();
print_test_header();
int countdown = 2;
auto handler1 = [&]() { countdown -= 1; };
#if 1 // breaks
auto handler2 = handler1;
#else // handler2 gets a different lambda type, passes
auto handler2 = [&]() { countdown -= 1; };
#endif
upcxx::rpc(upcxx::rank_me(),
upcxx::operation_cx::as_lpc(upcxx::current_persona(), handler1) |
upcxx::operation_cx::as_lpc(upcxx::current_persona(), handler2),
[]() {}
);
while(countdown != 0)
upcxx::progress();
print_test_success(true);
upcxx::finalize();
}
Comments (3)
-
-
reporter - changed status to resolved
This fixes issue 266 and issue 267.
266 required adding an integer "tag" to
completions_state
types which indexes their nesting depth in the class hierarchy to permit disambiguation of like-typed event handlers.267 required casting logic in
completions_state
to only give a&&
reference to the last handler in the chain.regression tests added:
test/regression/issue266.cpp
test/regression/issue267.cpp
→ <<cset dd132be1cb88>>
-
reporter Merged in completion_rvalrefs (pull request #128)
Completion handler fixes. Fixed issue 266. Fixed issue 267.
Approved-by: Dan Bonachea
→ <<cset a3648dba9d7c>>
- Log in to comment
Bulk roll-over of unresolved issues to next milestone