Regression introduced: value type in context in rule_parser started changing

[andreasbuhr]

A regression was introduced in c674e94.

Since that commit, the call method of rule_parser which does take an Attribute by reference uses the type of that Attribute to construct the context.
Since that commit, _val(ctx) in the actions can be whatever the consumer passes as Attribute to call().
But the value in the context, and thereby _val(ctx) in the actions, should always be the attribute of the rule_parser.

This becomes a problem when the rule_parser is used in an opt_parser. The opt_parser relies on the fact that it can pass its optional into the underlying parser, because the std::optional<Foo> can be constructed from Foo. But then therein, I suddenly get std::optional<Foo> as _val(ctx) in my actions, where I assume it would be just a Foo.

I'll create a pull request with a reproducer.

[andreasbuhr]

Reproducer in #295

[tzlaine]

Oof. This turns out to be a very deep issue. Within a semantic action applied to a rule, we want _val(ctx) always to produce a value of the rule's attribute type. Well, unless the user has opted into the out-param system, in which case, _val should probably produce whatever value has been given to the associated rule. That's not what's happening here though -- the rules are being used in a top-level parse that returns a result, not a parse that fills in a result. However, the rules are being invoked with an out-param as an implementation detail within the parser.

In order to fix this, it turns out that I need to change the way rule parers are invoked throughout the entire library, and I need to condition how they are called on the presence or absence of an out-param at the top level. Or at least I think that's right.

That's major surgery. So, while I intend to fix this, it's too late for the upcoming Boost release.

Thanks for the repro; it helped a lot.

[andreasbuhr]

Thanks for looking into it @tzlaine.