Imported From: https://issues.scala-lang.org/browse/SI-6489?orig=1
Reporter: @jrudolph
Affected Versions: 2.10.0-M7

@xeno-by said:
I wouldn't call that a blocker. But I will try to fix it in one of the subsequent point releases.

@jrudolph said:
No, it's no blocker. For some reason this was the default and I couldn't change the priority.

@retronym said:
Denys, I believe your the addition of positions to ToolBoxes will fix this bug.

In the macro context, def parse is implemented:
scala/src/compiler/scala/reflect/macros/contexts/Parsers.scala

@densh said (edited on Aug 29, 2013 12:51:09 PM UTC):
I wonder if we even need toolbox there any more. I'll look into it after qq pr.

@densh said:
Johannes, can you please clarify what kind of positions do you expect?

As far as I understood your last paragraph you'd like a tree generated by:

c.parse("foo bar")

to have positions within the current file where c.parse was called instead of fake temporary one generated just for parsing?

@jrudolph said (edited by @xeno-by on Sep 6, 2013 12:35:39 PM UTC):
There are two things: when I originally filed the bug, trees generated by parse didn't have any positions set. So, any position is better than that. The most useful in this case would be a position that would assume the string given to parse is a complete unit and offsets are into that string. In your example "foo" would have offset 0 and "bar" would have offset 4 and a synthetic unit.

The other idea was, that you are usually not parsing static stuff but stuff coming into the macro as literal string trees. These literal strings will have position from their original file, obviously. However, you would usually don't parse the complete literal string but only a part of it. In this case I would like the parsed tree's positions to point to the right segment in the original file.

We would need a parse method with a signature similar to this:

def parse(literalString: Literal, offset: Int, length: Int): Tree

It would take the specified slice of the literal string and call the normal parse method on it but would then use the resulting positions only as an offset into the original literal string position.

As an example, consider a macro call someDSLEval("stuff scala[3 + 12]"). The macro would parse the literal string and figure out that there's a scala expression embedded in it that needs to be parsed. So it would call

parse(literal, 12, 6) // 12 = offset of '3' in string, 6 = length of expression

The resulting tree for 3 + 12 should then have positions pointing to the '3' inside the original string in the file calling the macro, etc.

I guess the use-case for this is getting less important with string interpolation basically providing other means for embedding scala expressions in strings but still having something like this would enable custom string interpolation schemes.

@retronym said:
scala/scala#2935