`lexeme[alpha >> *alnum]` gets resolved into wrong overload of `parse_sequence` that expects fusion sequence with mismatched number of elements

[JhnW]

Hi.
I'm using boost 1.88 (latest on conan). This looks to me like another occurrence of the same bug/issue or just a missdesign that is problematic for people that I've seen around many times.

template <typename Iterator>
void parse_test(Iterator first, Iterator last)
{
    auto f_printer = [](auto& ctx){ std::cout <<"A:"<< std::endl; };
    auto const identifier = x3::lexeme[x3::alpha >> *x3::alnum]; // problematic line
    auto const function_call_def =  identifier >> "(" >> x3::double_ >> ")";
    const auto paarser = function_call_def[f_printer];
    bool r = phrase_parse(
        first,
        last,
        paarser,
        x3::space
        );
    std::cout<<"R: "<<r<<std::endl;
}

This code causes an assertion:

        // If you got an error here, then you are trying to pass
        // a fusion sequence with the wrong number of elements
        // as that expected by the (sequence) parser.
        static_assert(
            actual_size >= expected_size
          , "Size of the passed attribute is less than expected."
        );

from home/x3/operator/detail/sequence.hpp:140:25

Problematic line is auto const identifier = x3::lexeme[x3::alpha >> *x3::alnum]; Removind x3::lexeme and use const auto identifier = x3::alpha >> *x3::alnum; make code passing.

Also using BOOST_SPIRIT_DEFINE helps but i didn't see why I need to use this idiomatic flow.

[saki7]

Edited your code to enable syntax highlighting.

X3 is officially feature-frozen and only accepts security patches now. For details, please see README.

Regarding your report, I think it involves a quite significant semantic changes in the attribute determination of Spirit. While I agree that the existing behavior is somewhat unintuitive, it requires a non-trivial changes in core.

This needs investigation in X4, not X3.

[saki7]

Actually your comment saying "bug/issue or just a missdesign" is very correct. I think this is some sort of design mistake but I'm not 100% sure how to fix it (yet). So it technically needs more investigation; adding "need more info" label.

[saki7]

cc @yaito3014: I think this potentially affects the semantic meaning of is_substitute in your fork. The ideal solution would be the most intuitive one, that is we accept both the original code and the worked around code without requiring any changes in applications. However I'm not sure why the current behavior differs, and I'm not sure if the "ideal" solution is technically implementable.