#2254: startup: add missing mpi header include

[nlslatt]

Fixes #2254.

[JacobDomagala]

Would forward declaring MPI_Comm resolve the issue, or we actually need the header there?

[github-actions]

Pipelines results

PR tests (clang-9, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-13, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-13, alpine, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (intel icpx, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-12, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (gcc-9, ubuntu, mpich, zoltan, json schema test)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-11, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

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

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (gcc-12, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-14, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (clang-10, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

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

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (gcc-11, ubuntu, mpich, trace runtime, coverage)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (intel icpc, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

Compilation - successful

Testing - passed

Build log

---

PR tests (nvidia cuda 11.2, gcc-9, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

/vt/src/vt/pipe/pipe_manager.impl.h(133): warning: missing return statement at end of non-void function "vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&vt::vrt::collection::lb::GreedyLB::collectHandler, Target=vt::objgroup::proxy::ProxyElm<vt::vrt::collection::lb::GreedyLB>]"
          detected during:
            instantiation of "auto vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&vt::vrt::collection::lb::GreedyLB::collectHandler, Target=vt::objgroup::proxy::ProxyElm<vt::vrt::collection::lb::GreedyLB>]" 
/vt/src/vt/objgroup/proxy/proxy_objgroup.impl.h(202): here
            instantiation of "vt::objgroup::proxy::Proxy<ObjT>::PendingSendType vt::objgroup::proxy::Proxy<ObjT>::reduce<f,Op,Target,Args...>(Target, Args &&...) const [with ObjT=vt::vrt::collection::lb::GreedyLB, f=&vt::vrt::collection::lb::GreedyLB::collectHandler, Op=vt::collective::PlusOp, Target=vt::objgroup::proxy::ProxyElm<vt::vrt::collection::lb::GreedyLB>, Args=<vt::vrt::collection::lb::GreedyPayload>]" 
/vt/src/vt/vrt/collection/balance/greedylb/greedylb.cc(222): here

/vt/src/vt/pipe/pipe_manager.impl.h(133): warning: missing return statement at end of non-void function "vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&MyObj::handler, Target=vt::objgroup::proxy::ProxyElm<MyObj>]"
          detected during instantiation of "auto vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&MyObj::handler, Target=vt::objgroup::proxy::ProxyElm<MyObj>]" 
/vt/examples/callback/callback.cc(147): here

/vt/src/vt/pipe/pipe_manager.impl.h(133): warning: missing return statement at end of non-void function "vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&colHan, Target=vt::vrt::collection::VrtElmProxy<MyCol, vt::Index1D>]"
          detected during instantiation of "auto vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&colHan, Target=vt::vrt::collection::VrtElmProxy<MyCol, vt::Index1D>]" 
/vt/examples/callback/callback.cc(153): here

/vt/src/vt/pipe/pipe_manager.impl.h(133): warning: missing return statement at end of non-void function "vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&MyObj::handler, Target=vt::objgroup::proxy::ProxyElm<MyObj>]"
          detected during instantiation of "auto vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&MyObj::handler, Target=vt::objgroup::proxy::ProxyElm<MyObj>]" 
/vt/examples/callback/callback.cc(147): here

/vt/src/vt/pipe/pipe_manager.impl.h(133): warning: missing return statement at end of non-void function "vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&colHan, Target=vt::vrt::collection::VrtElmProxy<MyCol, vt::Index1D>]"
          detected during instantiation of "auto vt::pipe::PipeManager::makeSend<f,Target>(Target) [with f=&colHan, Target=vt::vrt::collection::VrtElmProxy<MyCol, vt::Index1D>]" 
/vt/examples/callback/callback.cc(153%0D%0A%0D%0A%0D%0A ==> And there is more. Read log. <==

Build log

---

PR tests (nvidia cuda 12.2.0, gcc-9, ubuntu, mpich)

Build for db329f8 (2024-03-25 17:23:01 UTC)

/vt/lib/CLI/CLI/CLI11.hpp(1029): warning #2361-D: invalid narrowing conversion from "double" to "unsigned long"
          TT { std::declval<CC>() }
               ^
          detected during:
            instantiation of "vt::CLI::detail::is_direct_constructible<T, C>::test [with T=std::vector<std::string, std::allocator<std::string>>, C=double]" based on template arguments <std::vector<std::string, std::allocator<std::string>>, double> at line 1041
            instantiation of class "vt::CLI::detail::is_direct_constructible<T, C> [with T=std::vector<std::string, std::allocator<std::string>>, C=double]" at line 5005
            instantiation of "void vt::CLI::Option::results(T &) const [with T=std::vector<std::string, std::allocator<std::string>>]" at line 5034
            instantiation of "T vt::CLI::Option::as<T>() const [with T=std::vector<std::string, std::allocator<std::string>>]" at line 7315

Remark: The warnings can be suppressed with "-diag-suppress <warning-number>"

/vt/lib/CLI/CLI/CLI11.hpp(1029): warning #2361-D: invalid narrowing conversion from "int" to "unsigned long"
          TT { std::declval<CC>() }
               ^
          detected during:
            instantiation of "vt::CLI::detail::is_direct_constructible<T, C>::test [with T=std::vector<std::string, std::allocator<std::string>>, C=int]" based on template arguments <std::vector<std::string, std::allocator<std::string>>, int> at line 1041
            instantiation of class "vt::CLI::detail::is_direct_constructible<T, C> [with T=std::vector<std::string, std::allocator<std::string>>, C=int]" at line 5005
            instantiation of "void vt::CLI::Option::results(T &) const [with T=std::vector<std::string, std::allocator<std::string>>]" at line 5034
            instantiation of "T vt::CLI::Option::as<T>() const [with T=std::vector<std::string, std::allocator<std::string>>]" at line 7315

Testing - passed

Build log

---

[nlslatt]

Would forward declaring MPI_Comm resolve the issue, or we actually need the header there?

This was a change I made in my working copy a while back. Now that I think about it, the missing header file may not have been related to my problem at all. I think this was when a problem with modules in my environment was mixing mpich into my OpenMPI and breaking everything. We can probably get away with either your suggestion or doing nothing at all.

[lifflander]

Would forward declaring MPI_Comm resolve the issue, or we actually need the header there?

This was a change I made in my working copy a while back. Now that I think about it, the missing header file may not have been related to my problem at all. I think this was when a problem with modules in my environment was mixing mpich into my OpenMPI and breaking everything. We can probably get away with either your suggestion or doing nothing at all.

I think it does not hurt to just explicitly include it here. It will get included later on without question, so it shouldn't increase compile times to include it here I believe.