Re: Linking error when changing > to >>

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

$0.03
Seth


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi