-
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
scala 3: ExplicitResultTypes #1583
Comments
With a minimal build:
I m able to compile and run the following code
|
Hi all, as part of GSoC 2022 I'm currently working on cross compiling |
To clarify, we've gone towards the "Other possible implementation", so this is therefore blocked by #1680 |
Any news maybe? It's been a year since the last comment |
Hi @guizmaii ! Unfortunately there hasn't been any work on that topic since the GSoC last year. I am the only maintainer with limited time and no longer use Scala in my day-to-day job, so the last few months have been merely about keeping Scalafix up to date with the ecosystem. Contributions are of course very welcome! |
Potentially, could we reuse the presentation compiler module that will come for 3.3.2 with a potential fallback on the metlas mtags? Did we discuss that at any point? That is a binary compatible interface https://github.com/scalameta/metals/blob/63a65d297c0c70173869603e8f1cf0950a665cd6/mtags-interfaces/src/main/java/scala/meta/pc/PresentationCompiler.java#L136 |
TIL: https://contributors.scala-lang.org/t/stable-presentation-compiler-api/6139 & scala/scala3#17528 💪 🤩
We haven't, I was not aware that the mtags implementation had effectively been upstreamed - it looks like a somewhat low-hanging fruit to integrate it to scalafix! I am unsure about the need for a Java API wrapper (thinking about the classloading penalty mostly), as we already build Scala 3 artifacts thanks to the 2022 GSoC. There are a few items to iron out before publishing, but there is nothing particularly complex. The biggest challenge was obviously the lack of scalameta quasiquote support in Scala 3, preventing many community rules to easily cross-build and therefore requiring support for loading 2.13 quasiquotes-backed community rules with scalafix-cli_3 if we want a smooth transition to |
We don't have to do a separate classloader for sure, we needed it in Metals mostly for supporting multiple Scala versions at the same time.
Yes! I almost managed to get it cross publishing, I should get back to it soon. |
Any news on this front @tgodzik ? |
I will take a look at a PoC if I have time on the weekend. |
So this PoC seems to work -> https://github.com/scalacenter/scalafix/compare/main...tgodzik:scalafix:add-inferred-type?expand=1
Some further work:
@bjaglin What do you think about this approach? Is there anything disqualifying about it? Currently the only thing that is really changed is defnType method and the constructor |
Adapt Explicit result types for Scala 3
The current state
ExplicitResultTypes
rule calls the scala 2 presentation compiler to infer types for eachval
,def
orvar
. To make this rule available for scala 3, we need to re-write it to interface this time with the Scala 3 presentation compiler, in other words,ExplicitResultTypes
rule for Scala 3, need to be written in Scala 3.How to implement ?
The actual design of Scalafix requires that the module
scalafix-rules
uses the same Scala Version than theScalafix-cli
module. To be able to use the Scala 3 presentation compiler, the rule needs to be rewritten in Scala 3 and thereforescalafix-cli
needs to be able to load a Scala 3 rule.Most likely implementation
ExplicitResultTypes
that provides the minimum needed methods for it to work. The interface would look like below:ExplicitResultTypes
rule needs aSemanticDocument
, that cannot be passed as a parameter to the java method, so each implementation of this rule will need to recreate it from its relative path.fix
method would return a list ofPosition
andString
, which should be enough to create ascalafix.Patch
.global
instance needs also to be created differently depending on the Scala Version. We can maybe stop usingScalafixGlobal
and use directlyscala.tools.nsc.interactive.Global
(in Scala 2) anddotty.tools.dotc.interactive.InteractiveDriver
(in Scala 3).ScalafixGlobal
is almost only wrapping theGlobal
from the presentation compiler. In this Java interface, it would be an Object, and then each implementation would cast it as aGlobal
instance orInteractiveDriver
instance depending on the Scala version.Here is an example of the interface implemented by Metals to deal with the same issue. Their
global
is calledPresentationCompiler
, and in their case, they only infer the type for one position, whereasExplicitResultTypes
needs to do it for the entire file.The module
Scalafix-cli
orScalafix-rules
(still need to be defined) would need some specific code to be able to classload the right jar ofExplicitResultTypes
, in other words either the version written in Scala 2 or Scala 3. (link to metals that does that, or other project that does that too)Write the new
ExplicitResultTypes
for scala 3, that implements theExplictResultTypesInterface
interface. We can definitely get inspired by Metals implementation forinferType code action
(link)Other possible implementation
If we are able to cross compiler scalafix-core, scalafix-cli in Scala 3 , it should be possible to write a specific version of Explicit Result types for Scala 3.
The text was updated successfully, but these errors were encountered: