-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Progress] - start utilizing data
in diagnostics to forward "quickfixes" to tools
#17337
Closed
5 tasks done
Labels
Comments
2 tasks
Alright with the latest nightlies this now works when using the latest sbt and the latest Bloop version. I'll go ahead and close this for now with the hopes that more actions can be added than the initial 3 in #17561. We can also add feature requests in the Discussions for specific ones. |
LuciferYang
pushed a commit
to apache/spark
that referenced
this issue
Jul 27, 2023
### What changes were proposed in this pull request? The pr aims to upgrade sbt from 1.9.2 to 1.9.3. ### Why are the changes needed? 1.The new version brings some improvment: Actionable diagnostics (aka quickfix) Actionable diagnostics, or quickfix, is an area in Scala tooling that's been getting attention since Chris Kipp presented it in the March 2023 Tooling Summit. Chris has written the [roadmap](https://contributors.scala-lang.org/t/roadmap-for-actionable-diagnostics/6172/1) and sent sbt/sbt#7242 that kickstarted the effort, but now there's been steady progress in build-server-protocol/build-server-protocol#527, scala/scala3#17337, scala/scala#10406, IntelliJ, Zinc, etc. Metals 1.0.0, for example, is now capable of surfacing code actions as a quickfix. sbt 1.9.3 adds a new interface called AnalysisCallback2 to relay code actions from the compiler(s) to Zinc's Analysis file. Future version of Scala 2.13.x (and hopefully Scala 3) will release with proper code actions, but as a demo I've implemented a code action for procedure syntax usages even on current Scala 2.13.11 with -deprecation flag. 2.Full release notes: https://github.com/sbt/sbt/releases/tag/v1.9.3 3.v1.9.2 VS v1.9.3 sbt/sbt@v1.9.2...v1.9.3 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Pass GA. Closes #42141 from panbingkun/SPARK-44536. Authored-by: panbingkun <[email protected]> Signed-off-by: yangjie01 <[email protected]>
ragnarok56
pushed a commit
to ragnarok56/spark
that referenced
this issue
Mar 2, 2024
### What changes were proposed in this pull request? The pr aims to upgrade sbt from 1.9.2 to 1.9.3. ### Why are the changes needed? 1.The new version brings some improvment: Actionable diagnostics (aka quickfix) Actionable diagnostics, or quickfix, is an area in Scala tooling that's been getting attention since Chris Kipp presented it in the March 2023 Tooling Summit. Chris has written the [roadmap](https://contributors.scala-lang.org/t/roadmap-for-actionable-diagnostics/6172/1) and sent sbt/sbt#7242 that kickstarted the effort, but now there's been steady progress in build-server-protocol/build-server-protocol#527, scala/scala3#17337, scala/scala#10406, IntelliJ, Zinc, etc. Metals 1.0.0, for example, is now capable of surfacing code actions as a quickfix. sbt 1.9.3 adds a new interface called AnalysisCallback2 to relay code actions from the compiler(s) to Zinc's Analysis file. Future version of Scala 2.13.x (and hopefully Scala 3) will release with proper code actions, but as a demo I've implemented a code action for procedure syntax usages even on current Scala 2.13.11 with -deprecation flag. 2.Full release notes: https://github.com/sbt/sbt/releases/tag/v1.9.3 3.v1.9.2 VS v1.9.3 sbt/sbt@v1.9.2...v1.9.3 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? Pass GA. Closes apache#42141 from panbingkun/SPARK-44536. Authored-by: panbingkun <[email protected]> Signed-off-by: yangjie01 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a follow-up to the work outlined in this issue. While the work in that
issue focused around forwarding the
DiagnosticCode
andDiagnosticRelatedInformation
, this issue is meant to track the work that is necessary to start utilizing thedata
field in theDiagnostic
in order to forward quick fixes right from the compiler to your editor. Just to given an example, here a POC that was done during the Scala Tooling Summit showing a fixcoming from the compiler and being consumed from IntelliJ.
227951211-dd28ccdc-9f2c-4090-8c74-793fae191cd0.1.mov
Like the other issue there are a fair amount of steps to start utilizing data in
this way. I've outlined the various steps below:
edits
key which contains and array ofWorkspaceEdit
s. This structure is now also being utilized by tools likescala-cli and other tools like Metals are ready to handle them. While this makes sense in BSP land, it's possible that it we could avoid some of the complexity that exists in the
WorkspaceEdit
and use a more minimal format in sbt-interface/compiler that later gets turned into a workspace edit later on.data
(or whatever representation we have) needs to be added toProblem
in sbt so that everything can use it.actions()
toProblem
sbt/sbt#7242ScalaDiagnostic
in diagnostic data scalameta/metals#5338Just to give a few examples, here are some candidates that came up during the discussions around this:
I can update this as I get more details, but just creating this to start tracking progress on this.
The text was updated successfully, but these errors were encountered: