Imported From: https://issues.scala-lang.org/browse/SI-8259?orig=1
Reporter: @xeno-by
See #7044

@gkossakowski said:

Hopefully, a relative file + a long wouldn't increase the size of our classfiles much.

Relative to what?

Also, I'll lower the priority of this issue. Critical seems to be a little bit too high.

@xeno-by said:
Relative to the package the class is in. Concretely, something that's written into the SourceFile attribute of the classfile.

Btw do you know any way to read SourceFile given a java.lang.Class?

@gkossakowski said:
I see. Makes sense.

I don't think you can read any of class file attributes using reflection (including SourceFileAttribute).

@dragos said:
Since Java reflection won't give you even the name of the source file, I think it's fine for the Scala implementation to behave the same.

Moreover, positions have a wide contract: they need to be able to retrieve a source file (with contents), get the line number based on an offset, and many others implemented in terms of SourceFile. Since the application may run somewhere without any sourcefiles in sight, you'd be re-implementing positions to only work for some methods, and not others. Maybe it's better to consider an alternative interface, if this serves an important use-case (what's the main use-case for this enhancement?)

@xeno-by said:
The motivation for this enhancement comes from the fact that positions are second-class citizens in our reflection API. This is fine from an implementation PoV, but we can definitely do a better job in exposing positions to the wide public (code analysis tools, editor plugins).

The main use-case here is "go to definition" functionality for precompiled code. Way back then, when I was hacking ENSIME, we had to use associatedFile + ASM to parse the SourceFile attribute, in order for it to work. Jason tells me that there's some presentation compiler API that deals with this, but not everyone has a luxury / complexity budget of running a presentation compiler.

The Position API is indeed quite big right now. I've somewhat addressed that by deprecating a lot of convenience methods, but Position.source is still there and it still exposes a huge API surface. That's something that I'll have to work on in Scala 2.12.