So I googl'ed a bit, but no information other than the sparse:
-Yrangepos Use range positions for syntax trees.
Ok. And I know I need to use it if I want to capture source fragments in a macro.
Now my two questions are:
The issue introducing -Yrangepos back when makro was spelt Burmak(r)o is motivated by your use case.
A -X option suggests permanence, while a -Y could disappear at any time, which means it could become the default behavior.
Perhaps it hasn't because of bugs and crashes.
At a team meeting written up by Moors:
Range positions [martin]
Respecting range positions - decay in the ide which has to do with the fact that transformations in the typer or parser don’t respect range positions
- every checked in change - automatically check range positions
- range positions = not just a position point but start and end, contained in tree nodes (RangePosition is a subclass of Position)
- there is map of RangePositions in CompilationUnit
invariants:
- range positions of child nodes are contained in range pos of parent nodes
- no overlap (except for transparent range positions)
- rangepos cover whole program
problems:
- templates
- for
check files contain positions
rangeposition(start,point,end).focus == offsetposition(point) // escape from non-overlap invariant
In 2012, PR validation with -Yrangepos failed frequently; it was fixed, but turned into a nightly validation to reduce resources.
Hubert offered these notes:
A few things about rangepos:
- if you try to run any code with 'scalac -Ybrowse:typer -Yrangepos FILE.scala' you will see that most of the trees have range positions.
- some don't, yes, that's a bit unfortunate but we are trying to improve on that - actually whenever you find such in Yrangepos mode it is possible that it is a bug. The situation has improved dramatically from 2.9 to 2.10.0-snapshots.
- syntactic trees are often assigned offset positions (this is something you might be experiencing but I would have to see an example)
- for the compiler we only care if range positions are valid up to (and including) typer. after that, we don't care. You are running your tool after refchecks from what I can see, this can interfere with a couple of transformations that happen in refchecks which can manipulate/assign range- or offset- positions.
It might seem easy to switch to range positions, because basic math, but there are still bugs like this one that demonstrate the extra labor involved in assigning positions when synthesizing or restructuring a tree.
Although range positions are needed for the presentation compiler, they aren't in the critical path for batch compilation. With more resources to improve robustness, maybe they could flip the switch.