1260: Fix active messaging functor inference using the FunctorExtractor

[JacobDomagala]

Fixes #1260

[github-actions]

PR tests (gcc-5, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (gcc-10, ubuntu, openmpi, no LB)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (clang-3.9, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (clang-5.0, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (clang-8, alpine, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (gcc-6, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (gcc-8, ubuntu, mpich, address sanitizer)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (gcc-9, ubuntu, mpich, zoltan)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (nvidia cuda 10.1, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (nvidia cuda 11.0, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (intel 18.03, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (intel 19, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (gcc-7, ubuntu, mpich, trace runtime, LB)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[codecov]

Codecov Report

Merging #1330 (b1f37a2) into develop (8337311) will decrease coverage by 0.03%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1330      +/-   ##
===========================================
- Coverage    82.69%   82.66%   -0.04%     
===========================================
  Files          760      760              
  Lines        28682    28699      +17     
===========================================
+ Hits         23719    23724       +5     
- Misses        4963     4975      +12     

Impacted Files	Coverage Δ
src/vt/messaging/active.h	73.43% <ø> (ø)
examples/collection/transpose.cc	95.71% <100.00%> (ø)
examples/hello_world/hello_world_functor.cc	100.00% <100.00%> (ø)
src/vt/messaging/active.impl.h	99.25% <100.00%> (+0.02%)	⬆️
tutorial/tutorial_1b.h	100.00% <100.00%> (ø)
src/vt/topos/location/location.impl.h	90.49% <0.00%> (-3.69%)	⬇️

[github-actions]

PR tests (clang-9, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[github-actions]

PR tests (clang-10, ubuntu, mpich)

Build for b1f37a2

Compilation - successful

Testing - passed

Build log

[PhilMiller]

I really like what this does. I want to request an extension to cover updating the codebase as broadly as possible, but that's asking for merge conflicts. Let's get this integrated, and then clean things up across the board in a follow-on PR.

[PhilMiller]

Could the same thing be done to the interfaces on objgroup and collection proxies?

[JacobDomagala]

This PR is merely just a bugfix for Active send/broadcast when used with Functor handler. For any arbitrary handler we're limited by C++14's lack of using the object as template argument, without specifying its type first.

If we really would want to get rid of explicit message type, I think the best we can do currently is:

template <typename HandlerType, HandlerType handler>
send(MsgPtrThief<typename FunctionExtractor<HandlerType >::MsgType >msg, ...)

Then we could provide helper macro like so:

#define VT_HANDLER(handler) decltype(&handler), &handler

which would make the call to send look like this:

send<VT_HANDLER(myHandler)>(my_msg);

Example: https://godbolt.org/z/fK6xvjWa8

[lifflander]

Look good

[JacobDomagala]

I just realized that this change enforces the user to have a Functor with only single operator() defined. Otherwise it won't compile. I think I will have to update this PR