-
Notifications
You must be signed in to change notification settings - Fork 185
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
feature: ExplicitResultTypes for Scala 3 #2023
Conversation
25384fa
to
69c827f
Compare
Exciting! I will have a look at it some time this week. |
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.
That looks promising, thanks for putting this together!
In terms of workflow, we could merge this quite early and mutualize code / enable more tests as we go, since nothing is published for Scala 3 anyway.
I will try to dust off #1680 in mid/late August since that remains a prerequisite. I had put it on hold as I was watching scalameta/scalameta#3347 (do you know if you or anyone else will allocate time to it by the way?), but I guess we could release experimental Scala 3 versions that would only allow rules written without quasiquotes, with the 2.13/3 sandwitch.
private def supportPresentationCompilerInDotty(scalaVersion: String) = { | ||
scalaVersion.split("\\.").take(3).map(_.toInt) match { | ||
case Array(3, minor, patch) => minor > 3 || minor == 3 && patch >= 4 | ||
case _ => false | ||
} | ||
} |
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.
Since we control the runtime of scalafix, and we'll first publish scala3 artifacts with 3.3.4 or later, this should always be true. If that's correct, I assume we don't need coursier and we can declare the dependency statically in scalafix-rules_3?
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.
We could, but wouldn't we need to publish the rules for every Scala version then, not just binary? Rules are not released for every scala version, right? Potentially, we could compile the rule with 3.3.x and use them for later versions while overriding the compiler and presentation compiler versions.
Also I commented out using 2.13 compiled rules for Scala 3, but I can make it work with coursier.
Ok, I am getting closer to a finish. I left some TODOs I want to still address, but there is nothing major. I've seen some test failure on one of JDK versions earlier so I will also check it out (I think we need to use JDK 11 at a minimum for the Scala 3 tests, so might need to disable the tests there) The biggest change I did is extracting most of the methods to a common base trait, but also enabled to use presentation compiler as a fallback for Scala 2. I noticed why we might be getting some failures in the tests (those removed for now), so I will also take a look.
I need to get back to it, I want to get something ready here and will be back to scalameta. |
385b1b1
to
1cbaae7
Compare
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala-3/scalafix/internal/rule/ExplicitResultTypes.scala
Show resolved
Hide resolved
1cbaae7
to
f91b2c4
Compare
Another fun observation is that running tests with static dependency on the compiler seems much faster than the dynamic one. I am not sure what it's caused by, I was pretty sure that separate classloaders are almost zero cost. |
Ach, I know what is happening, we are loading a separate classloader each time for each new file 😨 |
Right, we'd have to amortise the classloading cost across files, and ideally across invocations, to keep CPU/IO/RAM at a reasonable level when |
a5aae38
to
2c9e4f9
Compare
Ok, switched to using presentation compiler statically if the minor version of Scala 3 is the same and for dynamic loading I added caching which should fix things. |
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.
Thanks for all the work!
I had a look at infrastructure rather than actual code of the rule, since we can iterate on that easily after.
I'd like to sort out 2 things (mentioned in comments) before we merge:
- whether we want mtags or not (I think we can do without it)
- move input/output files to
scala
instead of copying toscala-3
when possible
scalafix-rules/src/main/scala-3/scalafix/internal/rule/ExplicitResultTypes.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala-3/scalafix/internal/rule/ExplicitResultTypes.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala-2/scalafix/internal/rule/ExplicitResultTypes.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala-3/scalafix/internal/rule/ExplicitResultTypes.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala/scalafix/internal/pc/Embedded.scala
Outdated
Show resolved
Hide resolved
scalafix-rules/src/main/scala-2/scalafix/internal/rule/ExplicitResultTypes.scala
Outdated
Show resolved
Hide resolved
I will probably be back to this next week, sorry for the delay! |
No worry, it gave me some time to finalize my PR about publishing cli_3.x.y #2034, in light of all discussions here. I am going to merge it very soon since it's already way too big. Commits should be self-describing, but here are the highlights to help you rebase (I can do it if you prefer?)
|
@tgodzik let me know if you don't have bandwidth to handle it this week, I can try to find time for this during the weekend, ahead of the upcoming Scalafix release next week (for the new Scala 2.x and 3 LTS releases). |
I was thinking of finishing scalameta/scalameta#3939 first, so probably I would get back to it later. If you have time and the will you are welcome to try and finish this PR 👍 Otherwise, I will probably get back to it next week. |
Ok, ni problem, I'll invest (some) time by Monday (most likely tonight and Saturday), we'll see how far I can get!
This would mean scalameta would be published for Scala 3 but quasiquotes wouldn't be available right? I think for scalafix it wouldn't change anything (switching to these new artifacts would make backward compatibility with community rules in 2.13 harder actually). I'd like to provide ExplicitResultTypes first, and then look at #2041 in the coming week/months since it's much more tricky to have a smooth transition for rule authors. |
We have quasiquotes partly ready, so I would want to unblock that |
I'll try to address outstanding comments and merge this PR this week-end since I have some bandwidth |
Well, it clearly didn't happen (life happened), but I have a 15h train ride this Friday 27th, so I will take care of this before cutting a release. |
No worries. I also planned to get back to it, but dealing with other bugs proved to be more urgent :/ |
2c9e4f9
to
1153521
Compare
I'll address comments as separate commits this afternoon. I am targeting to merge this tonight and cut a release now that 2.12.20, 2.13.15, and 3.3.4 are out. |
1153521
to
61dc47b
Compare
cb79adc
to
eeb0235
Compare
1ee6bf8
to
ed29190
Compare
They would have been useful for 2 things. 1. Support early Scala 3 versions (mtags) Considering RemoveUnused already requires a minimum Scala 3 version, and that we have presentation compiler for LTS patch releases, I don't think it is a big deal. 2. Support Scala 3 from cli_2 (mtags-interfaces + PC) Since Scalafix (build) clients have been selecting the cli version based on the target for years, and we found a backward-compatible way to let them ask for a given Scala 3 minor version, the migration path to cli_3 is easy. In both cases, dynamic loading was needed, causing potential resolution issues and more classloader isolation overhead.
ed29190
to
fe41df2
Compare
Thanks @bjaglin for your work on this! I can do a follow ups with any issues that show up. Or especially getting all the tests working the same or similar enough like in Scala 2 |
Approach: use the stable Scala 3 presentation compiler available since 3.3.2
There is still plenty to do, and I am not 100% sure about the approach, but it's a start. Tests are passing but some outputs are different the Scala 2 ones. I also found some issues in some of the tests, I removed them until I can fix them in the compiler.
TODO:
fix issues in the compiler(non-blocking?)separate tests for LTS and Nextwith both on the latest it seem ok, but we might need some compat at some point