Compiler error (when building a component) in SST serialization header when using CCE

[stonea]

Depending on the compiler I use, sometimes I run into the following error when I try and build a third party SST component that makes use of serialization:

In file included from /home/users/stonea/sst/sst-core/install/include/sst/core/serialization/serialize.h:436:0,
                 from /home/users/stonea/sst/sst-core/install/include/sst/core/serialization/serializable.h:16,
                 from /home/users/stonea/sst/sst-core/install/include/sst/core/mempool.h:15,
                 from /home/users/stonea/sst/sst-core/install/include/sst/core/activity.h:15,
                 from /home/users/stonea/sst/sst-core/install/include/sst/core/event.h:15,
                 from /home/users/stonea/sst/sst-core/install/include/sst/core/interfaces/stringEvent.h:15,
                 from cell.cpp:2:
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h: In lambda function:
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h:108:80: error: parameter packs not expanded with ‘...’:
                 [](std::variant<Types...>& obj) { obj.template emplace<INDEX>(); }...
                                                                                ^
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h:108:80: note:         ‘INDEX’
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h: At global scope:
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h:108:83: error: expansion pattern ‘<lambda>’ contains no argument packs
                 [](std::variant<Types...>& obj) { obj.template emplace<INDEX>(); }...

This is referring to a template that was added to SST in #1344.

For some reason it seems like it's expecting us to unpack the parameters within the lambda instead of outside of it.

I'm not strong at template metaprogramming, so I tried prompting an LLM tool to "refactor so the thing the parameter pack expression (...) is being applied to is factored out into a separate template" (thinking that doing so would disambiguate where ... is being applied. The tool suggested the following:

template <typename Variant, size_t Index>
constexpr void set_variant_index(Variant& obj) {
    obj.template emplace<Index>();
}

template <typename... Types>
template <size_t... INDEX>
constexpr void (*serialize_impl<std::variant<Types...>>::set_index<std::index_sequence<INDEX...>>[])
    (std::variant<Types...>&) = {
        &set_variant_index<std::variant<Types...>, INDEX>...
    };

Which seems to work in the sense that my code now compiles and simulates fine. At a cursory glance this looks like it should be a valid change.

@leekillough, maybe you could take a quick look to see if this suggested fix makes sense or if there's some other simple syntactic fix for this.

I'm compiling on a Cray-EX machine using Cray Clang, here's some version information:

> cc --version
Cray clang version 19.0.0  (cc4d36e4ff3377d45f0e6e892b5dacd82009a0ca)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cray/pe/cce/19.0.0/cce-clang/x86_64/bin
Build config: +assertions

This is with a build of sst-core that's on the devel branch. Here's the hash: 8ebb1689ed58776c6dd9643fda60a3b4caa09ff2.

[leekillough]

It seems to be confused at the two usages of ... in the lambda expresssions. One expands Types... while the other expands the entire lambda expression with INDEX as the pack parameter.

I will look at your proposed solution and try some other workarounds which avoid two ... pack expansions in the same expression, such as using auto& for the lambda function parameter (the auto might get autodeduced when the lambda is converted to a pointer to a function).

[leekillough]

I wrote a reduced test case based on the current devel code, and tried it on a variety of compilers on https://godbolt.org/z/17ExGKE83 (you can browse the compilers on the code, and see if you can find one which fails):

#include <array>
#include <cstddef>
#include <utility>
#include <variant>

template<typename, typename = void>
class serialize_impl;

template <typename... Types>
class serialize_impl<std::variant<Types...>>
{
    void operator()(std::variant<Types...>& obj, size_t index)
    {
        set_index<std::index_sequence_for<Types...>>::array.at(index)(obj);
    }

    template <typename>
    struct set_index;

    template <size_t... INDEX>
    struct set_index<std::index_sequence<INDEX...>>
    {
        static constexpr std::array<void (*)(std::variant<Types...>& obj), sizeof...(INDEX)> array = {
            [](std::variant<Types...>& obj) { obj.template emplace<INDEX>(); }...
        };
    };
};

template class serialize_impl<std::variant<int, long, double>>;

I could not find one which failed with your error, but I don't think Godbolt supports CCE.

But if you can try replacing [](std::variant<Types...>& obj) with [](auto& obj), that also compiles fine for me, and it removes the Types... expansion inside of the expansion of INDEX ...:

    template <size_t... INDEX>
    struct set_index<std::index_sequence<INDEX...>>
    {
        static constexpr std::array<void (*)(std::variant<Types...>& obj), sizeof...(INDEX)> array = {
            [](auto& obj) { obj.template emplace<INDEX>(); }...
        };
    };

The auto& obj makes the lambda a "generic lambda" (artificially templated), and when the non-capturing lambda array element initializer is converted to the function pointer array element type void (*)(std::variant<Types...>& obj), the auto& obj is automatically deduced to std::variant<Types...>& obj. This avoids expanding Types... inside of the expansion of INDEX.... It's expanded in the std::array outer declaration, but it's not expanded during each element's initialization. This might fix the issue you saw.

There are bugs in GCC ( 88417 71954 85282 ) which do not allow template specializations of variable templates to be defined inside of classes, and with some compilers that Sandia uses in its testing, I've seen linker errors when variable template specializations are defined in certain ways.

After #1344 but before #1395, a variable template was specialized outside of the serialize_impl class, which had a long nested template syntax. With #1395, the specialized variable template defined outside of the class was replaced with a specialized class (struct) template with a static constexpr data member. This allows us to define the partial specialization inside of serialize_impl, and does not need complicated nesting of templates, or fully-qualified names (A::B::C), to define it outside of the class.

I would try the auto& obj trick above, and see if that fixes it, because the original error message suggests to me that the nested uses of parameter pack expansions (Types... and INDEX...) is triggering it.

Or it could be a different issue with the compiler not recognizing INDEX as a parameter pack across lambda function boundaries. In the two error messages, the first seems to be saying that INDEX was never expanded with ... (maybe because it's inside of a lambda and ... is outside of the lambda), and the second seems to be saying that ... outside of the lambda has no pack to expand, for the same reason. See this, this, this and this

Is your error after #1395 (currently in devel), or did it occur with #1344 as well? I would want to know the status of both. If it occurs with both, I'll have to look at your workaround, which looks like it's moving the definition outside of the class, and it is using a named function's address rather than a non-capturing lambda implicitly converted to a function pointer, perhaps to get around this bug of not being able to expand parameter packs of entire lambda expressions where the pack parameter is inside the lambda. If it is indeed due to expanding lambda expressions across parameter packs, I can create a shorter version of your workaround which is still defined in-class and is more concise.

I've run into many errors on different platforms, so I have to make sure it works under all of our test environments. I am testing templates to their limits.

[leekillough]

There is a possible fix in #1447

[stonea]

I tried replacing the [](std::variant<Types...>& obj) with [](auto& obj) and it still errors out:

/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h: In lambda function:
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h:98:58: error: parameter packs not expanded with ‘...’:
             [](auto& obj) { obj.template emplace<INDEX>(); }...

The fix in #1447 does work though.

[stonea]

Is your error after #1395 (currently in devel), or did it occur with #1344 as well?

Checking out a273250 I see the same error:

/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h: In lambda function:
/home/users/stonea/sst/sst-core/install/include/sst/core/serialization/impl/serialize_variant.h:108:80: error: parameter packs not expanded with ‘...’:
                 [](std::variant<Types...>& obj) { obj.template emplace<INDEX>(); }...
                                                                                ^

[leekillough]

@stonea: Please verify devel and close as completed.

[stonea]

Yes, your PR fixed it. Thanks Lee!