You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Advanced semantic rules such as ExplicitResultTypes or ExplicitNonNullaryApply using the presentation compiler via ScalafixGlobal require the build scalaVersion to match scalafixScalaBinaryVersion, and potentially the full Scala release used by Scalafix.
Rules themselves should not suggest actions to fix a mismatch (as rules might not be run from sbt for example). That should be up to the rules runner (mill, sbt, CLI, metals, etc), which should be able to intercept information upon execution failure and derive a relevant call for action, or even update state automatically (maybe with a warning saying it should be made persistent).
// Rule.scala// making it non-sealed will force clients to pattern-match `_` and be forward compatible/*sealed*/traitInputRequirementcaseclassBinaryScalaVersion(binaryScalaVersion: String) extendsInputRequirementcaseclassScalaVersion(scalaVersion: String) extendsInputRequirementcaseclassRequiredScalacOption(scalacOption: String) extendsInputRequirementcaseclassIncompatibleScalacOption(scalacOption: String) extendsInputRequirement
...
protecteddeffailedRequirements(
inputScalaVersion: String,
inputScalacOptions: String
):List[InputCompilationRequirement]) =Nil
bjaglin
changed the title
Expose scala versions mismatch as typed errors in SemanticRule#withConfiguration
Expose scala versions mismatch as typed errors in Rule#withConfiguration
Jul 3, 2020
bjaglin
changed the title
Expose scala versions mismatch as typed errors in Rule#withConfiguration
Let rules expose scala versions constraints
Jul 3, 2020
Advanced semantic rules such as
ExplicitResultTypes
orExplicitNonNullaryApply
using the presentation compiler viaScalafixGlobal
require the buildscalaVersion
to matchscalafixScalaBinaryVersion
, and potentially the full Scala release used by Scalafix.Rules themselves should not suggest actions to fix a mismatch (as rules might not be run from sbt for example). That should be up to the rules runner (mill, sbt, CLI, metals, etc), which should be able to intercept information upon execution failure and derive a relevant call for action, or even update state automatically (maybe with a warning saying it should be made persistent).
Implementation: I am not sure the return type of https://www.javadoc.io/static/ch.epfl.scala/scalafix-core_2.12/0.9.18/scalafix/v1/SemanticRule.html#withConfiguration(config:scalafix.v1.Configuration):metaconfig.Configured[scalafix.v1.Rule] is rich enough to allow that level of information, so we need to discuss how this could be implemented in a backward-compatible way. Suggestion:
Somewhat related to #1143
The text was updated successfully, but these errors were encountered: