Re: Linking error when changing > to >>
Larry Evans <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
On 11/21/2016 08:05 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 > > By `parse_rule` stub, do you mean what's generated by the > BOOST_SPIRIT_DEFINE_ macro? > > By `attribute transformation` do you mean something like the > extract_rule_attr overloads from here: > > https://github.com/cppljevans/spirit/blob/ExagonLinkingError/include/boost/spirit/home/x3/nonterminal/rule.hpp#L112 > > or something else? > Or maybe by `attribute transformation` you mean the code in lines 312-323 of: https://github.com/cppljevans/spirit/blob/ExagonLinkingError/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp What about moving that code into a replacement for the existing extract_rule_attr? Using gdb it produces the same value as the existing extract_rule_attr at least in one case. However, I can't tell yet from reading the code if it will produce an attribute of types rule<...>::attribute_type, which is needed to get the BOOST_SPIRIT_INSTANTIATE to work. -regards, Larry ------------------------------------------------------------------------------