search

scala / bug

Scala 2 bug reports only. Please, no questions — proper bug reports only.
https://scala-lang.org
232 stars 21 forks source link

Symbol.pos returns NoPosition at runtime #8259

Open scabug opened 10 years ago

scabug commented 10 years ago

On the one hand, we don't pickle positions. On the other hand, we can't even read the SourceFile classfile attribute via official API in java.lang.Class. This means that it's currently impossible to use reflection API to figure out the source file and line number where a symbol was defined.

I think the best solution here would be to pickle symbol positions. Hopefully, a relative file + a long wouldn't increase the size of our classfiles much.

scabug commented 10 years ago

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

scabug commented 10 years ago

@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.

scabug commented 10 years ago

@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?

scabug commented 10 years ago

@gkossakowski said: I see. Makes sense.

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

scabug commented 10 years ago

@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?)

scabug commented 10 years ago

@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.