Hey guys! I have a question about organizing imports with scalafix OrganizeImports rules. Probably not the right place to ask (point me in the right direction please).
Is there any option to have imports organized the following way?
import org.apache.kafka.clients.consumer.{
ConsumerRebalanceListener,
OffsetCommitCallback,
Consumer => ConsumerJ,
ConsumerGroupMetadata => ConsumerGroupMetadataJ,
ConsumerRecords => ConsumerRecordsJ,
OffsetAndMetadata => OffsetAndMetadataJ,
OffsetAndTimestamp => OffsetAndTimestampJ
}Current implementation just put them all on a single line like this
import org.apache.kafka.clients.consumer.{Consumer => ConsumerJ, ConsumerGroupMetadata => ConsumerGroupMetadataJ, ConsumerRebalanceListener, ConsumerRecords => ConsumerRecordsJ, OffsetAndMetadata => OffsetAndMetadataJ, OffsetAndTimestamp => OffsetAndTimestampJ, OffsetCommitCallback}
@Z1kkurat, thanks for reaching out. For liancheng/scala-organize-imports#43, the fix I made is to make sure that if an import statement is already organized according to the configuration, OrganizeImports should preserve the original format (line breaks, spaces, etc.). As @olafurpg pointed out, Scalafix is not responsible (or capable in many cases) to emit well formatted code, and you'll need tools like Scalafmt for that.
The fix I made makes OrganizeImports idempotent. For example, if you run Scalafix first to organize the imports, run Scalafmt to format the code, and then run Scalafix again, the 2nd Scalafix run should not reformat your code since your imports are already organized. Please refer to this section for more details.
In the case you reported, the original import statement is not organized yet (not sorted properly), so OrganizeImports updated and reformatted it.
val patch = doc.tree.collect { case t: Template =>
val otherDefinition = t.stats.filterNot(_.isInstanceOf[Defn.Def])
val defDefinition = t.stats.collect({ case d: Defn.Def => d }).sortBy(_.name.value)
Patch.replaceTree(t, t.copy(stats = otherDefinition ++ defDefinition).syntax)
}def from the others and then sorting it.
Probably a dumb question, but how can I find type information for a reference?
E.g.
val r: zio.Runtime[Any] = ???
// Somewhere in the program
r.platformI 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
Scalafix 0.9.28 with support for Scala 3
We are happy to announce the release of Scalafix 0.9.28.Huge thanks to bjaglin and taisukeoe for their great contributions (release notes: 1, 2).
This release brings many improvements, in particular it introduces support of Scala 3 for both users and rule authors.
Highlights of this last release:
- Support Scala 3: it’s still experimental and some built-in rules may not work as expected. We started testing some community rules on Scala 3, one of them is the popular organize-imports rule. Most tests are passing except the ones relying on the
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) - Update Tthe Scalafix.g8 template: to make it simple to test rules against Scala 3 source files. To test it you can run
sbt new scalacenter/scalafix.g8 - Drop SemanticRuleSuite and SyntacticRuleSuite: those two classes were already deprecated since 0.9.18 and we have created a migration rule to make the migration automatic for most cases. This will unlock the upgrade of scalatest for next versions.
- Caching is now enabled by default on sbt-scalafix: successive invocations of the
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. - Support of Scala 2.13.6 & -Xsource:3
- Support on-compile specific configuration: scalacenter/scalafix#1375
I was trying to code my first rewrite rules at: https://gist.github.com/rom1dep/4127f5c0a2000703fe6f22d7dd9ad3c2
to help this project out: scalafx/scalafx#352 , but I'm very new to this, and quite convinced now that I'm taking this problem from the wrong end. Is scalafix the right tool for the job? And if so, any advise as to a more reasonable approach?
4 replies
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
11 replies
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.Surface will 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?