Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 01 09:13

    mlachkar on gh-pages

    Deploy website Deploy website … (compare)

  • Dec 01 09:13

    mlachkar on gh-pages

    Deploy website Deploy website … (compare)

  • Dec 01 09:11
    bjaglin commented #1505
  • Dec 01 09:10

    bjaglin on main

    Update sbt-scalafix to 0.9.33 Merge pull request #1504 from s… (compare)

  • Dec 01 09:10
    bjaglin closed #1504
  • Dec 01 09:10

    bjaglin on main

    Update scalafmt-core to 3.1.2 Merge pull request #1506 from s… (compare)

  • Dec 01 09:10
    bjaglin closed #1506
  • Dec 01 01:59
    scala-steward opened #1506
  • Dec 01 01:59
    scala-steward opened #1505
  • Dec 01 01:59
    scala-steward opened #1504
  • Nov 29 18:51
    mnd999 closed #1503
  • Nov 29 18:51
    mnd999 commented #1503
  • Nov 29 09:25
    tgodzik commented #1503
  • Nov 29 09:20
    liff commented #1501
  • Nov 29 09:15
    mlachkar commented #1503
  • Nov 29 09:14
    mlachkar commented #1501
  • Nov 27 13:50
    mnd999 edited #1503
  • Nov 27 13:49
    mnd999 commented #1503
  • Nov 27 10:50
    mnd999 commented #1503
  • Nov 26 13:45
    mlachkar commented #1501
Ólafur Páll Geirsson
@olafurpg
@tusharmath cool! Thank you for sharing!
What happens when you have docstrings or comments?
Tushar Mathur
@tusharmath

Original

trait AB {
  /*
   * Some description about `b`
   */
  def b: Unit
  def a: Unit
}

Fixed

trait AB {
  /*
   * Some description about `b`
   */
  def a: Unit
  def b: Unit
}
@olafurpg
BTW I was able to solve the recursive problem somehow.
Right now the comments get really messed up :P
Markus Appel
@markusa380

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

Manel Pérez
@manelp

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

Brice Jaglin
@bjaglin
@manelp it doesn't ring a bell, do you have a repro? are you using sbt-scalafix?
Manel Pérez
@manelp
Yes, sbt-scalafix. I'll try to reproduce it in a small project.
Manel Pérez
@manelp

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

Brice Jaglin
@bjaglin
thanks for the repro! you should follow up on https://gitter.im/scalameta/scalameta or https://github.com/scalameta/scalameta/issues, that's where semanticdb-scalac is maintained (although I am not sure where the responsibility lies between the 2 plugins and the compiler - which by the way will see a 2.12.14 release anytime now, so your problem might be gone )
Manel Pérez
@manelp
:+1:
Meriam Lachkar
@mlachkar

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 Wunused scalacOption 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 scalafix task 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
Chris Kipp
@ckipp:matrix.org
[m]
🎉 congrats that a huge release!
1 reply
Romain DEP.
@rom1dep
Hello there!
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
Ondra Pelech
@sideeffffect

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
Romain DEP.
@rom1dep
how am I supposed to replace a tree with another tree rather than with a string?
38 replies
Ondra Pelech
@sideeffffect
Hello, will you publish a new version which supports ScalaMeta 4.4.20 (which supports Scala 2.12.14) anytime soon?
Brice Jaglin
@bjaglin
@sideeffffect i was waiting for a dependency release to address scalacenter/scalafix#1414, but I will just rollback, and tag
Ondra Pelech
@sideeffffect
thank you!
Brice Jaglin
@bjaglin
@/all Scalafix 0.9.29 is out, fixing 2 regressions introduced in 0.9.28 and adding support for Scala 2.12.14. Thanks @tgodzik for the quick turnaound as usual!
Ondra Pelech
@sideeffffect
Thank you @bjaglin for releasing this so quickly!!! :bow:
Ondra Pelech
@sideeffffect
Btw, one has to use scaluzzi 0.1.18 (not the newest 0.1.19) because of old metaconfig that is used in 0.9.29. Otherwise one gets
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)
Brice Jaglin
@bjaglin
Oops, that's scalacenter/scalafix#1418... That also means scaluzzi 0.1.19 or any rule built against Scalafix 0.9.28 making use of metaconfig.generic.Surface will not run on Scalafix<0.9.28, which is as concerning, if not more.
Brice Jaglin
@bjaglin
I am not sure what's going on here, given the linked overload in the 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?
Ólafur Páll Geirsson
@olafurpg
@bjaglin adding a new method is backwards compatible, but forwards incompatible. The scala-library jar is the only API that I'm aware of in the Scala community that guarantees forward compatibility, because it's very difficult to evolve a library without adding new methods that break forwards compatibility
As long as the latest Scalafix uses the latest metaconfig, then it should be able to support older versions of Scalafix rules (regardless of what version of metaconfig they use)
it's not too important to allow "latest version of custom rule works with older versions of Scalafix"
it's desirable, but impractical
Brice Jaglin
@bjaglin
@olafurpg thanks, I see! In that particular case, could we tweak https://github.com/scalameta/metaconfig/commit/df7731d981619837e88eb7c9e48913bc58f53622#diff-335f40226027fbc0a85b9fc7a4b4fc9f79df8ffba3ec34519f057295a0a7a00fR210 to avoid calling the new arity-2 constructor if classAnnotations is empty? it looks like a quick fix.
Brice Jaglin
@bjaglin
Also, I am wondering if scalafix-interfaces shouldn't handle eviction betters: metaconfig.generic.Surface was 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.
Ólafur Páll Geirsson
@olafurpg
Avoiding the 2-arity constructor when possible sounds good to me. Although it's unfortunate so much investment is needed to work around this bincompat issue
I'm on the fence about letting the tool classpath override the scalafix root classpath. Does that mean a community rule could override the internal classpath to use an older version of metaconfig/scalafix?
My intuition had been that community rules are more likely to lag behind on Scalafix versions instead of the other way around
Brice Jaglin
@bjaglin

Does that mean a community rule could override the internal classpath to use an older version of metaconfig/scalafix?

I was thinking the most recent one could evict the other (coursier fetch logic)

Although it's unfortunate so much investment is needed to work around this bincompat issue

macros make harder a problem already hard enough :)

Ólafur Páll Geirsson
@olafurpg
True, but without macros we would have other kinds of problems related to outdated boilerplate or buggy code generation scripts :)
does scalafix-interfaces download scalafix AND the custom rules in the same coursier resolution?
the older version is only evicted within a single resolution, and my understanding is that custom rules are resolved via a separate resolution (but I may be missing something)
Brice Jaglin
@bjaglin
Even though it's indeed 2 separate resolutions (the first one in scalafix-interfaces, and the second one in scalafix-cli), I naively thought the filtering strategy used to sandbox scalafix-cli behind scalafix-interfaces could be adapted so that classloaded rules share only 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.
Brice Jaglin
@bjaglin
Since the toolclasspath is most often known beforehand, we could add some methods in scalafix-interfaces that classload scalafix-cli AND custom rules in one go though. The problem I see is that the CLI itself wouldn't benefit from that, so for the same scalafix-cli/interfaces version, behavior would be different between a pure CLI invocation and one through a build tool / IDE.
Dario Abdulrehman
@dabd
Can you run scalafix rules on .sbt files? I wanted to apply https://github.com/liancheng/scalafix-organize-imports on these files as well.
Brice Jaglin
@bjaglin
@dabd only syntactic rules are supported on *.sbt files, so I am afraid you can't run that semantic rule
Dario Abdulrehman
@dabd
thanks @bjaglin
Michael Thomas
@Michaelt293
I'm wondering, is there a good way to go from a Symbol to the scala meta AST for that symbol?
Ólafur Páll Geirsson
@olafurpg
@Michaelt293 a symbol can be loaded from the classpath where you don’t have access to the sources. What would the AST contain?
You can render the signature of a symbol into Scala syntax, which you could parse
but you wouldn’t have the implementation then