Skip to content
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

[WIP] Migrate to 2.13 #3475

Closed
wants to merge 1 commit into from
Closed

[WIP] Migrate to 2.13 #3475

wants to merge 1 commit into from

Conversation

ckipp01
Copy link
Member

@ckipp01 ckipp01 commented Jan 5, 2022

When I saw scalacenter/bloop#1646 I knew I needed to try this out. I was curious how much work would be needed to migrate to 2.13. This is at least publishable locally now. There are still a lot of warnings, some tests to figure out etc, but I figured I'd throw this up here to give you an idea of the diff to migrate to 2.13.

Copy link
Member

@kpodsiad kpodsiad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, can't wait to have 2.13 in Metals.

) def b = 1
//@deprecated(
// message = "a",
// since = susan
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a quick look, final val susan = "Susan" should help.

@@ -4,6 +4,7 @@ import java.io.File

import scala.concurrent.ExecutionContext
import scala.concurrent.Future
import scala.jdk.CollectionConverters._
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was usually added via MetalsEnrichments and the DecorateAsScala/DecorateAsJava traits, I think we can just switch to AsJavaExtensions and AsScalaExtensions instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I started out with that, but then I realized there was a lot of places that only brought in MetalsEnrichments just to use those instead of just using them directly. Do you still think we should do this?

* If this doesn't scale because we have too many unrelated extension methods
* then we can split this up, but for now it's really convenient to have to
* remember only one import.
*/
object MetalsEnrichments
extends DecorateAsJava
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was usually added via MetalsEnrichments and the DecorateAsScala/DecorateAsJava traits, I think we can just switch to AsJavaExtensions and AsScalaExtensions instead.

Actually here, we could just replace those I think.

https://www.scala-lang.org/api/current/scala/collection/convert/AsJavaExtensions.html

@ckipp01
Copy link
Member Author

ckipp01 commented Jan 6, 2022

Again, until Bloop gets merged/publish I wouldn't spend a lot of time reviewing this. It was more of just an experiment to see what it'd take to get it to compile. So there is still quite a bit to do.

@kpodsiad
Copy link
Member

There are fresh artifacts on https://repo1.maven.org/maven2/ch/epfl/scala/bloop-launcher_2.13/ ;)

@ckipp01
Copy link
Member Author

ckipp01 commented Feb 13, 2022

Superseded by #3631

@ckipp01 ckipp01 closed this Feb 13, 2022
@ckipp01 ckipp01 deleted the 213 branch February 13, 2022 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants