-
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
remove dialect and use scalaVersion #1392
Conversation
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.
LGTM on using scalaVersion
to control the internal dialect passed to scalameta for parsing. A few docs & implementation details comments.
As discussed offline, for the record:
- this flag is not mandatory at the moment - it's only required for rules using the presentation compiler (
ExplicitResultTypes
amongst the built-in rules) to ensure compatibility at the class/pickle level - it would be redundant and confusing for the user to ask for another flag just for the dialect
- sbt-scalafix only passes it for semantic rules at the moment, but it's trivial to update it
- the current default is the runtime Scala version of Scalafix, so effectively 2.12 or 2.13, which does not change the default behavior for parsing sources
- 👍 for supporting a major version only (single int), to cover the use case of dialect selection via the CLI (or potentially in the configuration file itself) with as little provided information as possible (
--scala-version 3
).
assert(out.contains("Scala2")) | ||
} | ||
) | ||
// checkSemantic( |
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.
remove?
scalafix-tests/unit/src/test/scala/scalafix/tests/config/ScalaVersionSuite.scala
Show resolved
Hide resolved
Success(Minor(major, minor.toInt)) | ||
} | ||
case MajorPattern(major) => MajorVersion.from(major.toLong).flatMap(major => Success(Major(major))) | ||
case _ => Failure(new Exception(s"$s not a valid ScalaVersion.")) |
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.
case _ => Failure(new Exception(s"$s not a valid ScalaVersion.")) | |
case _ => Failure(new Exception(s"$s not a valid Scala version")) |
def from(s: String): Try[ScalaVersion] = { | ||
val version = s.split("-").head | ||
version match { | ||
case "Scala2" | "scala2" => Success(scala2) // not sure |
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.
not sure about supporting this syntax? Given the documentation of the flag, it seems a bit strange to me that the user would provide something else than x[.x[.x]]
. Maybe we can strip the potential heading [S|s]cala
before parsing?
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 think we can just not support this as you said.
} | ||
} | ||
|
||
private val longPattern = """\d{1,19}""" |
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 am guessing we can stick to 2? also you capture ints here, not longs
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.
you're right
} | ||
|
||
private val longPattern = """\d{1,19}""" | ||
private val BasicVersion = raw"""($longPattern)\.($longPattern)\.($longPattern)""".r |
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.
private val BasicVersion = raw"""($longPattern)\.($longPattern)\.($longPattern)""".r | |
private val FullVersion = raw"""($longPattern)\.($longPattern)\.($longPattern)""".r |
@@ -129,7 +127,7 @@ case class Args( | |||
@Description( | |||
"The Scala compiler version that was used to compile this project." |
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 are extending the use of this flag for syntactic rules, I think we should relax a bit the constraint of "prior compilation". Also, the reference to project
is a bit ambiguous, considering the other flags, I think files
would be more consistent.
"The Scala compiler version that was used to compile this project." | |
"The Scala compiler version that the provided files are targeting, or the actual version that was used to compile them when a classpath is provided." |
@@ -371,7 +368,7 @@ case class Args( | |||
settingInScala2: String, | |||
settingInScala3Opt: Option[String] | |||
): Option[String] = { | |||
if (scalaVersion.isEmpty || scalaVersion.startsWith("2")) { | |||
if (scalaVersion.value.isEmpty || scalaVersion.value.startsWith("2")) { |
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.
add helper on ScalaVersion
? Or Ordering
?
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.
yes definitely. It was just to make everything compiles
f765918
to
f0be46b
Compare
scalafix-cli/src/main/scala/scalafix/internal/interfaces/ScalafixArgumentsImpl.scala
Outdated
Show resolved
Hide resolved
@deprecated( | ||
"use fromInput(input: Input, scalaVersion: ScalaVersion) instead", | ||
"0.9.28" | ||
) | ||
def fromInput(inout: Input, dialect: Dialect): SyntacticDocument = { | ||
val tree = parse(inout, dialect).get: Tree | ||
fromTree(tree) | ||
} |
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.
you can remove this since it was never published, no?
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.
This method was there already.
@@ -169,6 +164,7 @@ ScalafixArguments withToolClasspath( | |||
* this must match the binary version available in the classloader of | |||
* this instance, as requested/provided in the static factory methods | |||
* of {@link Scalafix}. | |||
* @throws ScalafixException In case of an error parsing the scalaVersion. |
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.
the javadoc could be updated in the same way the CLI doc was updated
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.
ok
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.
the cli sentence is finally not that clear for me!
@Description(
"The Scala compiler version that the provided files are targeting, " +
"or the actual version that was used to compile them when a classpath is provided."
)
what we want is
- the full scalaverion that was used to compile the code source
- in the absence of the fullVersion, we require either the scala binary version of the code source, or the major scala Version
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 need at least the major, to know with which dialect to parse the code source, but some rules may require more..
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.
Something like that?
The major or binary Scala version that the provided files are targeting, or the full version that was used to compile them when a classpath is provided.
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.
ok!
FTR, I just ran into scalameta/scalameta#2323, so I think whatever the outcome of that discussion is, it's good that we hide the dialect and infer it based on |
I agree with you! |
Follows #1373