What's the effect of -Yrangepos other than giving me source locations in macros

Question

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:

• why is this not on by default?
• are there any side-effects to using it (such as increasing the class file size)?

Heterogenesis

Answer 1

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.

Taenia

Answer 2

I can only guess that scalac by default does not use range positions for performance reasons.

In regular compilation, positions are used only for error reporting and saving line number information into classfiles. Offset positions are enough to do that, so there's no point in doing all the work required to manipulate range positions.

I don't think that range positions incur any other cost than simple compilation speed.

Giotto

From local tests, compilation overhead seems minimal, so I'm guessing your "guess" is incorrect, and the issue is mostly robustness, as som-snytt answered. – Ragi