Support project view in TVP panel for Scala 3 #2859
Milestone
Comments
ckipp01
changed the title
|
To add a little more context, I'd expect this to work in Scala 3 like it does in Scala 2. However, even after some more classes I've been unable to get TVP to show local stuff in the tree view. Steps to recreate:
|
|
The reason is that TVP uses |
ckipp01
changed the title
So this applies for the Libraries section where dependencies are built with Scala 3, I assume. If I'm on the right track then For Scala 3 files local to a project, I imagine Could this extraction from JARs, abstracting over ScalaSig or TASTy, be in a SemanticDB utility along the lines of scalameta/scalameta#1566? |
|
@ches The only that is currently required is to add support of reading Tasty files at the place where TVP uses ScalaSig. Everything related to Semanticdb already works well and shouldn't be connected with this thing. |
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Sep 6, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Sep 11, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Sep 12, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Sep 13, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Oct 24, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
to tgodzik/metals
that referenced
this issue
Oct 26, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes scalameta#2859
tgodzik
added a commit
that referenced
this issue
Oct 27, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes #2859
tgodzik
added a commit
that referenced
this issue
Nov 8, 2023
Previously, we would read the classpath to create the metals view, which worked well for Scala 2, but needed a reimplementation for Scala 3. So now, instead of doing this reimplementation, which would probably need to use tasty and might be quite complex, I decided to base it on the same approach we use for inexing. This makes the feature more reliable since, we now used the same well tested functionaties as things like go to definition. Unfortunately, we might index the particular files the second time, because the basic indexing caches are reversed and finding all symbols in a file from those maps was much slower than just doing it the second time. We later cache that information the same way we did in the previous tree view implementation. So we won't use more memory and running the benchmarks show that the new approach is similarily fast: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 542.090 ± 61.953 ms/op ``` as compared to the previous: ``` [info] Benchmark Mode Cnt Score Error Units [info] ClasspathSymbolsBench.run ss 10 477.283 ± 93.933 ms/op ``` Also it seems we index much more information, since mtags index all symbols, which would also explain the slight difference in timings as I think the difference was 1300 symbols previously and 17000 after this change (number of symbols detected in the benchmarks) Fixes #2859
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am not sure this is a bug or the feature isn't support for scala 3 yet.
I created a new sbt project using scala3.g8 template. Then I created some classes and objects in the Main.scala file.
The project explorer only detected the package, nothing else were shown unlike the Libraries section,
Originally posted by @Fubuchi in #2855
The text was updated successfully, but these errors were encountered: