Re: Linking error when changing > to >>

On 11/19/2016 09:20 AM, Larry Evans wrote:
> On 11/12/2016 09:07 PM, Seth wrote:
>> On 12-11-16 23:14, Seth wrote:
>>> On 11-11-16 21:06, Exagon wrote:
>>>> So I think it has something to do with the type parser.
>>>> Maybe I did something wrong, please correct me if I did anything anywhere in
>>>> this example I shouldnt do when using boost spirit x3.
>>>> I spoke to Joel before to ask whether I could expect such a behaviour in
>>>> spirit x3 and he said no, so I think this is a bug.
>>> FWIW I tried to look into this with the bag-of-tricks I know for this
>>>
>>>  * It's not about attribute synthesis AFAICT (using semantic actions to
>>> sense the synthesized attributes confirms identical types).
>>>
>>> The linker error indicates that it is trying to invoke the `type` rule
>>> with the attribute bound to a fusion iterator, instead of the actual
>>> object. It's interesting that this works when compiling single-TU.
>>>
>>> This would mean that this is supported but a forgotten usage-patten of
>>> `parse_rule` which needs to be added to the macros for explicit
>>> instantiation?
>>>
>>>
>>> $0.02
>>>
>>> Seth
>>
>> After (much) more tinkering, indeed the problem seems to be that
>> `call_rule_definition` is called from inside `parse_rule`.
>>
>> However, the attribute transformation on the partitioned fusion
>> sequences (iterator ranges) happen only inside `call_rule_definition`.
>> Turns out, this is simply too late, because that means for TU-separation
>> we need to anticipate all the different ActualAttribute types that might
>> be passed to `parse_rule`.
>>
>> We might be able to move the attribute transformation into the
>> `parse_rule` stub - although I'm sure there could be a more elegant solution
>>
> I thought changing rule::parse as shown here:
>
> https://github.com/cppljevans/spirit/blob/e6a6dbcb6b5b2041cb6a14f7afcb0978d25032bd/include/boost/spirit/home/x3/nonterminal/rule.hpp#L140
>
> should work.  My reasoning was that attr must contain, somewhere,
> the actual rule's attribute; hence, just provide the needed
> extract_rule_attr overloads.  I tried it with just the
> fusion::iterator_range overload; however, that lead to a compile
> error which lead to the variant overload, but that lead to
> another compiler error about context.  That error is shown here:
>
> https://github.com/cppljevans/spirit/commit/e6a6dbcb6b5b2041cb6a14f7afcb0978d25032bd
>
> I'm trying to figure out a workaround, but maybe you have
> some ideas about a workaround, are am I going in wrong
> direction?
>
> TIA.
>
Latest change:

https://github.com/cppljevans/spirit/commit/a6d2e602bcd6a166e28bfa2ed15dc1ba0e7eb49a

solved compile problem, but now have runtime error about
bad_get:

terminate called after throwing an instance of 
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_get> 
 >'
   what():  boost::bad_get: failed value get using boost::get

I'll guess that can be solved by changing the variant to have the 
appropriate type in extract_rule_attr.

Does that sound OK?

TIA.

-Larry




------------------------------------------------------------------------------