Position error: synthetic tree contains non-synthetic tree

[etorreborre]

Hi,

I am using -Yrangepos with specs2 in order to be able to extract exact pieces of text from the interpolated bits when using string interpolation. 

At the same time I am trying to use macros to generate matchers for case classes. Unfortunately I run into position validation errors which I don't know how to fix:

[info] ======= Position error

[info] Synthetic tree [2336] contains nonsynthetic tree [2095]

[info] == Enclosing tree [2336] of type ValDef at [234]HelloWorldSpec.scala

[info]

[info] [L  13        ] #2336   [234]           ValDef     // term $1$

[info]

[info] == Enclosed tree [2095] of type Block at [218:229]HelloWorldSpec.scala

[info]

[info] [L  13        ] #2095   [218:229]       Block      // [Cat].name("

Is there a way to fix those errors by "forcing" a range position on the tree that is generated by the macro call? My guess was that being able to apply c.macroApplication.pos to the whole tree would be fine but that doesn't seem to be working.

Thanks.

Eric.

[Kevin Wright]

I've also run into this, specifically when trying to splice a fragment of pre-existing tree into a macro-generated tree, also because I was using range positions to capture the underlying code :)

The fix that worked for me was to duplicate the tree fragment before splicing.  As per: https://github.com/kevinwright/macroflection/blob/master/kernel/src/main/scala/net/thecoda/macroflection/Validation.scala#L75

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[etorreborre]

Thanks Kevin, I should have mentioned that I have also used your "trick" in the past and it served me well. 

In my current code though this doesn't seem to work. But I don't really understand how it works or where I should apply it specifically.

[Paul Phillips]

On Mon, Sep 2, 2013 at 4:24 PM, etorreborre <etorr...@gmail.com> wrote:

In my current code though this doesn't seem to work. But I don't really understand how it works or where I should apply it specifically.

In the recent past I closed a pull request unmerged out of frustration because this is how it was failing under -Yrangepos and I had no idea why. (I wasn't trying to influence anything related to positions.) In any case all I can tell you is that I can't complete my range positions work without making this go away, so I will, though this may or may not mean that I'll have anything to say about the present behavior. Positions require way too much idiosyncratic knowledge for something which should almost always be mechanically derivable from pre-existing positioned data.

[Jason Zaugg]

Try: https://github.com/scala/async/commit/c780810#L3R55.

Usually, you have to maintain the invariant that trees with offset positions *do not* enclose trees with range positions. Setting the positions to be "transparent" is an escape hatch from that check. The cost is that the IDE has to use a less efficient search algorithm to find a tree at a given position when doing things like "type of expression" or "hyperlinking".

It would be great if you can extract a test case for this and lodge a bug. The macro engine might be able to automatically mark the positions as transparent if the range positions invariants are not met.

-jason

[etorreborre]

Thanks Jason, this is working ok for me.

I tried to simplify the code to reproduce the range position error but unfortunately I wasn't able to do it. The project is publicly available though if you want to have a stab at it: https://github.com/etorreborre/specs2-macros. If you change this line to "case t => super.transform(t)" then the error should manifest itself again.

Eric.