-
Notifications
You must be signed in to change notification settings - Fork 43
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
add scalafixCallback
setting key to customize diagnostics reporting
#384
Conversation
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.
Thanks for the PR. I am curious about your use-case. I assume it's similar to what was discussed in scalacenter/scalafix#951?
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.
As I read again my "Can be set in ThisBuild or at project-level" suggestion, I realized I missed an important point in my first review - see inline comment below.
scalafixCustomResolvers = scalafixResolvers.value | ||
scalafixCustomResolvers = scalafixResolvers.value, | ||
logger = ScalafixInterface.defaultLogger, | ||
callback = scalafixCallback.value |
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.
Watch out for:
sbt-scalafix/src/main/scala/scalafix/internal/sbt/ScalafixInterface.scala
Lines 131 to 136 in c2777cf
fromToolClasspathMemo.getOrElseUpdate( | |
( | |
scalafixBinaryScalaVersion, | |
scalafixDependencies, | |
scalafixCustomResolvers | |
), { |
As it stands in the current state of this PR, a client might set different values for scalafixCallback
across projects, and see only one being used because of memoization.
We can either
- add
callback
as a cache key (using reference equality I guess?) - support only one value per build
callback = scalafixCallback.value | |
callback = (ThisBuild / scalafixCallback).value |
I would go for (1) for consistency with other configurable attributes of scalafixInterface
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.
Reopening this for visibility: given the current state of sbt-scalafix, there is a small limitation to be aware of in the solution (2) you went for. The cache is never flushed, so if a sbt command changed the state of the build and update ThisBuild / scalafixCallback
, you will get false positive cache hits.
This is a corner case, but depending on how you end up injecting a per-invocation scalafixCallback
to avoid mutability at that level, this could be annoying. If that's the case, we'll have to go for (1), as well as maybe keep the cache in a setting key to avoid leaking memory upon each sbt reload
because of a new JVM instance of ScalafixMainCallback
.
Oh, I didn't know the issue. I have same motivation 👍 |
d13e1fa
to
ea46fa7
Compare
Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
ea46fa7
to
83c3d10
Compare
Co-authored-by: Brice Jaglin <bjaglin@gmail.com>
scalafixCallback
setting key to customize diagnostics reporting
Nice. I just looked at your projects and I assume this PR is effectively a step towards xuwei-k/sbt-warning-diff#6. I'll be watching that - if you manage to do what you want with a custom |
For the record, I am planning to do a Scalafix release in a few weeks, in sync with the scala 2.x patch releases. Until then, you can try the snapshots. |
Towards scalacenter/scalafix#951