-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No way to find the original symbol for exported symbols #19444
Comments
Adding a field to a symbol is a huge undertaking which will make to codebase messier. We were very careful to have only few fields that can easily be copied and transformed. For instance, we had a demand recently that symbols should include the compiler version under which they were compiled. Sounds reasonable, but I suggested we refactor code elsewhere so that we don't need a new field. Generally, the design of the compiler follows the "no duplicated information" principle. If you add a field that you have to set manually but that could be recomputed in some way, you have created a possible loophole of information mismatches. That's why we generally don't do that, and rely on caches instead. So, can we compute this info somehow? First, can you find to the export statement that introduced an exported symbol? If yes, you can take the type of its qualifier tree (let's call it prefix.member(sym.name).suchThat(_.matches(sym)) |
What's the reproduction for this? I tried to build one in |
I think completions would work as that is a correct symbol, you would need to check definition suite for example. @odersky I wasn't talking about adding a field, I thought |
@tgodzik Ah I see. You wrote " |
The technique would work for sure, though I did try that for a bit and hit a wall, since if we have exported symbols from another file, is it possible to get the tree for that? Or is there a way via tasty to do that? |
Exports are reified in Tasty. So there should be an Export node in the tree of the file where the symbol comes from. It's just that we need to be able to find it. |
Do we have any similar logic somewhere that we could base the implementation on? |
I've tried a case in HoverDefnSuite, one in PcDefinitionSuite and one in TypeDefinitionSuite, after the one in CustomCompletionTests, and they all work. Could you provide a reproduction and clarify the expectation? |
I added this case in PcDefinitionSuite and it does fail. In what cases did it work for you? |
@Test def exports =
val code =
"""class BitMap
|class InkJet
|
|class Printer:
| type PrinterType
| def print(bits: BitMap): Unit = ???
| def status: List[String] = ???
|
|class Scanner:
| def scan(): BitMap = ???
| def <<status>>: List[String] = ???
|
|class Copier:
| private val printUnit = new Printer { type PrinterType = InkJet }
| private val scanUnit = new Scanner
|
| export scanUnit.scan
| export printUnit.{status as _, *}
|
| def status: List[String] =
| printUnit.status ++ scanUnit.sta@@tus""".stripMargin
check(code) |
Compiler version
3.4.0-RC1
Minimized code
We can get the example from the docs:
Output
Currently when using the exported symbols there will be no link to the original symbol, which means both semanticdb and the presentation compiler will not work properly. This most likely affects Intellij also.
Expectation
There is a
.sourceSymbol
filed, which could maybe link to the original symbol?The text was updated successfully, but these errors were encountered: