-
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
scalameta 4.9.x #1927
scalameta 4.9.x #1927
Conversation
6d8b555 causes core compilation to succeed, but docs2_13 to fail
That's because for some reason, coursier prefers 4.8.15 over 4.8.15+150-a7c0baa0-SNAPSHOT there:
Adding scalameta at the root does affect resolution, so it looks like Coursier is following nearest-win instead of latest-win (despite what's expected). lazy val docs = projectMatrix
.in(file("scalafix-docs"))
.settings(
+ libraryDependencies += scalameta,
Forcing eviction via ea2e835 |
ea2e835 exposes an incompatibility between mdoc and the latest scalameta SNAPSHOT
Following-up in scalameta/mdoc#842 |
f511e2c
to
3343cf8
Compare
Following-up in scalameta/scalameta#3546 |
scalafix/scalafix-core/src/main/scala/scalafix/internal/patch/ImportPatchOps.scala Line 203 in 61dce03
Another similar guard is impacted, although it causes a slight regression that might not be worth fixing:
|
119b399
to
f76d880
Compare
Coursier seems to prefer mdoc's scalameta 4.8.15 over core2_13's scalameta 4.8.15+150-a7c0baa0-SNAPSHOT. Adding scalameta as a top-level docs2_13 libraryDependencies does change this behavior, so I suspect Coursier is following nearest-wins semantics for some reason, while we expect it to following latest-wins semantics. http://eed3si9n.com/dependency-resolver-semantics#coursiers-latest-wins-semantics By using dependencyOverrides, we ensure that docs run are generated with the actual scalameta version used in scalafix, rather than the one used in mdoc.
Quasiquotes-generated trees have positions since scalameta#3450. Fixes: error: patch.md:168:1: token not found: Patch.removeImportee(importee"Future").showDiff() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ java.util.NoSuchElementException: token not found: at scalafix.util.TokenList.$anonfun$tok2idx$2(TokenList.scala:27) at scala.collection.immutable.Map$WithDefault.default(Map.scala:181) at scala.collection.MapOps.apply(Map.scala:176) at scala.collection.MapOps.apply$(Map.scala:175) at scala.collection.AbstractMap.apply(Map.scala:405) at scalafix.util.TokenList.leading(TokenList.scala:15) at scalafix.internal.patch.ImportPatchOps$.remove$1(ImportPatchOps.scala:229)
f76d880
to
5f4ef49
Compare
|
||
object ScalafixScalametaHacks { | ||
def resetOrigin(tree: Tree): Tree = tree.withOrigin(Origin.None) |
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.
unused since 1ab1d7e
@@ -200,7 +201,11 @@ object ImportPatchOps { | |||
allImports.filter(_.importers.forall(isRemovedImporter)) | |||
|
|||
def remove(toRemove: Tree): Patch = { | |||
if (toRemove.pos == Position.None) return Patch.empty |
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 brings false negatives now that quasiquotes have positions (since scalameta/scalameta#3425). This is effectively a very minor breaking change in the API.
https://github.com/scalameta/scalameta/releases/tag/v4.9.0
scalameta/scalameta#3425 is a non-backward compatible feature, as quasiquotes expand to code referencing
scala.meta.trees.Origin
which does not exist in 4.8.x.This means that Scalafix rules containing quasiquotes compiled against scalameta 4.9.x will cause link errors if ran on older Scalafix versions. As a result, we need a minor Scalafix bump when taking that in, despite the fact that it's "just" a minor bump in a SemVer lib (we could argue that a major bump of scalameta was needed, but backward compatibility guarantees with macros is not very well defined).Edit after v0.12.0 release
I originally warned rule authors of this in the release notes:
But this turns out NOT to be an issue with old scalafix-cli, as
scala.meta.trees.Origin
is a brand new symbol, properly resolved by the tool classpathURLClassLoader
which contains scalameta 4.9.x (which the parent scalafix-cli classloader containing scalameta 4.8.x reverts to).