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

remove dialect and use scalaVersion #1392

Merged
merged 1 commit into from
May 10, 2021
Merged

Conversation

mlachkar
Copy link
Collaborator

@mlachkar mlachkar commented May 7, 2021

Follows #1373

Copy link
Collaborator

@bjaglin bjaglin left a 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(
Copy link
Collaborator

Choose a reason for hiding this comment

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

remove?

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."))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
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
Copy link
Collaborator

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?

Copy link
Collaborator Author

@mlachkar mlachkar May 10, 2021

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}"""
Copy link
Collaborator

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

Copy link
Collaborator Author

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
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
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."
Copy link
Collaborator

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.

Suggested change
"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")) {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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

@mlachkar mlachkar force-pushed the scalaVersion branch 3 times, most recently from f765918 to f0be46b Compare May 10, 2021 10:55
@mlachkar mlachkar marked this pull request as ready for review May 10, 2021 10:56
@mlachkar mlachkar requested a review from bjaglin May 10, 2021 11:43
Comment on lines +40 to +47
@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)
}
Copy link
Collaborator

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?

Copy link
Collaborator Author

@mlachkar mlachkar May 10, 2021

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.
Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ok

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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..

Copy link
Collaborator

@bjaglin bjaglin May 10, 2021

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ok!

@bjaglin
Copy link
Collaborator

bjaglin commented May 11, 2021

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 scalaVersion (and potentially scalacOptions).

@bjaglin bjaglin mentioned this pull request May 11, 2021
5 tasks
@mlachkar
Copy link
Collaborator Author

I agree with you!

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.

2 participants