-
Notifications
You must be signed in to change notification settings - Fork 338
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
chore: migrate Metals to 2.13 #3631
Conversation
/** | ||
* Finds sources in the workspace when there is no available build tool. | ||
*/ | ||
final class WorkspaceSources(workspace: AbsolutePath) { | ||
def all: Traversable[AbsolutePath] = { | ||
def all: Generator[AbsolutePath] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had some issues getting walkFileTree
to work as an Interable
in the same way that it is now. Then it sort of dawned on me that all
here is only ever called in one place, inside of indexWorkspace
which itself is only ever called in WorkspaceFuzzBench.scala
and BaseWorkspaceSymboleSuite.scala
to index a workspace with a zip it seems. I assumed we have the custome File Visitor to be able to skip dirs that start with .
and not go down their subtrees, but seeing that this is only being used in tests it seemed way way easier to instead just use the built in listRecursive
on AbsolutePath
and just deal with the Generator that is returned. Is this ok or am I missing something?
ae1762e
to
c8328c9
Compare
Alright, we are finally all ✅, but I did cheat a bit and a couple things are ignored. I'll outline them below and continue to look at them, but I think others can now take a look over this.
One other thing we need to figure out is when do we want to pull the trigger on this? If we do it right in the middle (like now) it'll be a mess for client that need to resolve the metals artifact. It might be best to do a release, and then right after the release, merge this so that anything 0.11.2 or great can use 2.13 and everything else 2.12. wdyt? If that's fine, then I'd suggest we do a release soon so we don't have to keep this up to date with every pr, especially seeing that there are some other larger prs open. One other thing for maybe a follow-up pr. We default to Seq a lot. Should we be? Should we maybe instead be using Vector? |
Maybe? That depends on the situation I guess, small lists are also well optimized. Also, we can do a release soon, maybe with the bump to Bloop 1.4.13 |
c877514
to
5c9b899
Compare
8173f1f
to
b3e1636
Compare
Seeing that we just released, what do you all think of trying to get this merged in right away. That will make it much easier for clients since anything > 0.11.2 can look for 2.13 whereas everything else can be on 2.12. Doing it right after a release will result in the smoothest transition. There are basically 2 tests that I can't figure out that are unmarked above. One seems to be related to ordering and the other one I can reproduce locally. Other than that, I believe everything should be good to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow! This was a lot of great work! I left some comments, but nothing blocking, but I would do a follow up issue with things we still needed to improve, but this PR is already huge, so we can work on that later.
) | ||
println/*scala.Predef.println(+1).*/(MacroAnnotation/*example.MacroAnnotation.*/.decodeMacroAnnotation/*example.MacroAnnotation.decodeMacroAnnotation.*/) | ||
println/*scala.Predef.println(+1).*/(MacroAnnotation/*example.MacroAnnotation.*/.encodeMacroAnnotation/*example.MacroAnnotation.encodeMacroAnnotation.*/) | ||
println/*scala.Predef.println(+1).*/(deriveDecoder/*io.circe.derivation.package.deriveDecoder().*//*local0*/[MacroAnnotation/*example.MacroAnnotation#*/]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is /*local0*/
expect actually, is this coming from an implicit parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea this is another one I had a tricky time with since the way circe derivation was working here in 2.13 was way different so I did what I thought would test the same thing, but I'm actually a bit unsure.
| ] | ||
| } | ||
|} | ||
|/a/src/main/scala/a/User.scala | ||
|package a | ||
|import io.circe.derivation.JsonCodec | ||
|@JsonCodec case class User(name: String) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the code changed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the @JsonCodec
wasn't working the same way anymore and not actually showing an annotation the way we were testing before. So in order to still have this test show a working goto definition with an annotation I switched this to use Alex's dataclass library so we can use @data
and see that the @data
creates an apply that we can do a goto definition on.
tests/unit/src/test/scala/tests/decorations/SyntheticDecorationsLspSuite.scala
Outdated
Show resolved
Hide resolved
s"""|**Synthetics**: | ||
| | ||
|([fallbackStringCanBuildFrom](command:metals.goto?$fallbackParams)[[Int](command:metals.goto?$intParams)]) | ||
|([Char](command:metals.goto?$orderingParams)) | ||
|[[Char](command:metals.goto?$charParams)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this on separate lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I'm not really sure.
tests/unit/src/test/scala/tests/decorations/SyntheticHoverLspSuite.scala
Show resolved
Hide resolved
Sounds good! I can for sure follow this up with a couple tickets and missing points. I'm actually on holiday at the moment, so I might not be as responsive the next couple days until I get back, but wanted to at least bring attention to this right away since it'll be the easiest if we merge it as soon as we can. If you don't see any blockers feel free to merge, or if you do and still want to merge quickly, feel free to push on top of this. If not, I'll address them in a couple days and get to your questions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge this!
It looks like this PR introduced a regression in the indexing performance on Linux for large repositories 🤔
I'm not sure why that is yet, I'll add more details once I figure it out! |
Is that just on linux? The biggest change would probably be the Scala collections, so maybe anything related to that? |
Yes it's just on Linux. I've removed as many redundant Scala collections ops as I could (I'll open a PR), but that didn't help at all. I'm still investigating... |
I finally figured it out, and it was entirely caused by our environment 😮💨 🤦 Sorry for the noise and thanks for the great work 🚀 |
😅 please feel free to still pr the removal of the redundant Scala ops if you still have the changes |
No description provided.