bjaglin on v0.9.34
bjaglin on main
support scala 2.13.8 Merge pull request #1519 from b… (compare)
Probably a dumb question, but how can I find type information for a reference?
val r: zio.Runtime[Any] = ??? // Somewhere in the program r.platform
I want to find SymbolInformation for
r but it's always None, and r could be defined anywhere so I need to somehow lookup it's type?
Hi, is there any know problem with scalafix 0.9.27 and scala 2.12.13? I'm getting a trace showing the tree, I suppose from semanticdb, when I have any compilation error:
TRANSFORM: null TREE: ...
I've tried downgrading to scala 2.12.12 and it worked fine, and with scala 2.13.4 also works fine
Ok, I've found out that the problem is a combination of two compiler plugins:
name := "sbt-scalafix-test" version := "0.1" scalaVersion := "2.12.13" lazy val root = project .in(file(".")) .settings( addCompilerPlugin(scalafixSemanticdb), addCompilerPlugin("com.github.ghik" % "silencer-plugin" % "1.7.3" cross CrossVersion.full) )
With both enabled,
sbt compile finish with a success, but it shouldn't because there errors. Commenting out any of them solves the problem. Here's the repo were I've tried this: https://github.com/manelp/sbt-scalafix-test.
I will drop silencer since I can use
@nowarnnow and won't invest more time on this, but I leave it here for anyone who may face this problem
This release brings many improvements, in particular it introduces support of Scala 3 for both users and rule authors.
Highlights of this last release:
WunusedscalacOption which is not yet supported by Scala 3 compiler. Some other rules will work out-of-the box with Scalafix 0.9.28, even if the source files use features or syntax introduced in Scala 3. We invite all rule authors to test their rules against Scala 3 and to adapt, if needed, the required scalacOptions (example of the on-going liancheng/scalafix-organize-imports#179 on scalafix-organize-imports)
sbt new scalacenter/scalafix.g8
scalafixtask with the same arguments & configuration will be incremental. This was already the case when scalafixOnCompile was enabled, but we believe this can improve user experience also for users starting scalafix sporadically.
I'm getting unexpected errors when trying to upgrade to sbt-scalafix 0.9.28: zio/zio-prelude#634
[error] SemanticDB not found: core/shared/src/test/scala/zio/prelude/AssociativeFlattenSpec.scala [error] SemanticDB not found: core/shared/src/test/scala/zio/prelude/CoherentSpec.scala [error] SemanticDB not found: core/shared/src/test/scala/zio/prelude/SafeFunctionSpec.scala ...
How can I fix this? Thank you
Error: java.lang.NoSuchMethodError: 'void metaconfig.generic.Surface.<init>(scala.collection.immutable.List, scala.collection.immutable.List)' Error: at scalafix.internal.scaluzzi.DisableConfig$.<init>(DisableConfig.scala:162)
metaconfig.generic.Surfacewill not run on Scalafix<0.9.28, which is as concerning, if not more.
NoSuchMethodError- does https://github.com/scalameta/metaconfig/commit/df7731d981619837e88eb7c9e48913bc58f53622#diff-bb8e899325e39d9a28fc668670cf053128dd777a526390667b26fd7f83ceb047R15 get inlined? Interestingly, MiMa was added in that commit, but I guess it does not check for this kind of forward-compatibility?
classAnnotationsis empty? it looks like a quick fix.
metaconfig.generic.Surfacewas already loaded by the scalafix-cli classloader (with an old version) to parse the configuration, so the one in the
--toolclasspath(newer, required by the classloaded community rule) is effectively ignored. Assuming security is not a concern here, we could let toolclasspath evict dependencies from the internal classpath when using the high-level
withToolClasspathoverloads using coursier coordinates? Some IDE/build-tool integrations might lag behind community rules (see https://github.com/evis/scalafix-maven-plugin/commits/master for example). Related note: https://github.com/scalacenter/scalafix/commit/3694af653dde8c6c05a2af5051540a3f7f7870a6#diff-26de4adbd0ac932a910d1ec9c7b8a8784e07dc15a96313961a927194d96eef00R57-R61.
Although it's unfortunate so much investment is needed to work around this bincompat issue
macros make harder a problem already hard enough :)
scalafix.v1.*(or something like that) with the scalafix-cli classloader. But after looking at the code, I realized some scalameta/metaconfig types are exposed through
scalafix.v1.*, so that lack of clear boundaries makes it impossible to get both sandboxing AND class unicity across classloaders.
.sbtfiles? I wanted to apply https://github.com/liancheng/scalafix-organize-imports on these files as well.