Brice Jaglin

About Scalafix 2.11/2.13 usage in sbt: there was good progress over the last weeks, and https://github.com/scalacenter/scalafix/pull/1166 should be the last step, but what should be the strategy to promote rule...

I have had a similar issue on sources using the `wire` macro from https://github.com/softwaremill/macwire, resulting in `MissingSymbolException: com.softwaremill.macwire.Wired` (and that macro only, which should NOT exercise https://github.com/softwaremill/macwire/blob/d509b04bb95567a935497bbef186875c60fce13b/macros/src/main/scala/com/softwaremill/macwire/MacwireMacros.scala#L118). Changing in these...

I got a repro: https://github.com/bjaglin/scalafix/commit/d1d6afdd964cfe1835e248f649c0e4ad507234d2 My specific problem (which might not be the one originally reported, but looks very similar), is related to a broken runtime dependency: `"com.softwaremill.macwire" %% "macros"`...

@mlachkar, no since https://scalacenter.github.io/scalafix/docs/users/suppression.html#unused-suppression-warnings are just warnings, and [only errors trigger failure](https://github.com/scalacenter/scalafix/blob/e31e5c946a14bb3839ef5c087b660953a3485db8/scalafix-cli/src/main/scala/scalafix/internal/v1/DelegatingMainCallback.scala#L14), thus my first proposition.

> For me, the main issue is why do we have many unused Scalafix suppressions. Do you mean in the scalafix codebase itself?

Thanks for the report @mcanlas! From my understanding, you are seeing different behavior for the `OrganizeImports` rule depending on the way the semanticdb compiler plugin is set up in your...

Right, it looks like `-P:semanticdb:targetroot` is set by default in https://github.com/sbt/sbt/blob/dd00fc6cbe6dffa463136428d0bf0917eba80a3b/main/src/main/scala/sbt/plugins/SemanticdbPlugin.scala#L55. When manually injecting `-P:semanticdb:targetroot` in `scalacOptions`, do you get the same (faulty) behavior as when using the sbt 1.3.x...

@mcanlas are you still experiencing the issue? a repro is needed if we want to move forward with this

> Should it run on all configurations by default ? I guess you refer to the `or scalafixEnable itself?` comment? Here is my take on it a few months after...

If you meant that `scalafixAll` should target all configurations no matter if `scalafixEnable` was called before or not, then I believe we should take the discussion with scalafmt folks as...