Skip to content
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
ckipp01 opened this issue Apr 24, 2023 · 1 comment
Closed
5 tasks done
Labels
area:tooling itype:meta Issues about process/similar

Comments

@ckipp01
Copy link
Member

ckipp01 commented Apr 24, 2023

This is a follow-up to the work outlined in this issue. While the work in that
issue focused around forwarding the DiagnosticCode and DiagnosticRelatedInformation, this issue is meant to track the work that is necessary to start utilizing the data field in the Diagnostic 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 fix
coming 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:

Just to give a few examples, here are some candidates that came up during the discussions around this:

  • implement all members
  • add type for recursion automatically if possible
  • auto import implicits
  • add an import enabling a (experimental/compatibility/...) language feature - in some (most?) situations this could be alternatively achieved (globally rather than just in a single file) by adding a compiler option but this seems much more complicated as each build tool specifies compiler options in a different way and the compiler should be build tool agnostic
  • add missing case clauses in a pattern match - E029
  • remove redundant/disallowed keyword - E015, E037, E062, E063, E064, E065

I can update this as I get more details, but just creating this to start tracking progress on this.

@ckipp01 ckipp01 added stat:needs triage Every issue needs to have an "area" and "itype" label area:tooling and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 24, 2023
@smarter smarter added the itype:meta Issues about process/similar label Jul 6, 2023
@ckipp01
Copy link
Member Author

ckipp01 commented Jul 12, 2023

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.

@ckipp01 ckipp01 closed this as completed Jul 12, 2023
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 <pbk1982@gmail.com>
Signed-off-by: yangjie01 <yangjie01@baidu.com>
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 <pbk1982@gmail.com>
Signed-off-by: yangjie01 <yangjie01@baidu.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:tooling itype:meta Issues about process/similar
Projects
None yet
Development

No branches or pull requests

2 participants