Metals: Refactor: insert missing abstract members

[gabro]

Is your feature request related to a problem? Please describe.
When implementing an abstract class or trait, it's useful to complete all the abstract members with stubs.

Describe the solution you'd like
Given something like

trait A {
  def someMethod(a: String): Int
  def someOtherMethod(b: String): String 
}

class B extends A {
// ^^^^^^^^^^^^^^^^^
// Error: class B needs to be abstract, blabla...
}

I would like a code action on B that allows to quickly implement all abstract members with stubs, resulting in:

class B extends A {
  override def someMethod(a: String): Int = ???
  override def someOtherMethod(b: String): String = ???
}

Describe alternatives you've considered
Mostly two alternatives exist:

• copy paste the stubs from the error message generated by the compiler
• use the "Implement all members" completion (which is basically the same as the code action I'm proposing, except it's triggered differently)

Additional context
I think this should be a "quickfix" code action in response to the specific compiler error.

Also, I believe it makes sense to have both the completion and the code action:

• when implementing the trait for the first time the completion comes in handy, since I'm already typing
• when I'm dealing with a compiler error because I forgot a member or a new abstract member was added to the trait, then the code action is more intuitive than triggering a completion.

Search terms:
abstract members, traits, interface

[tanishiking]

I'm working on this, and it's roughly working.🙌 Though there're still some to-dos before finishing up this, I think I can submit a PR maybe next weekend.

• Robust regex to capture a diagnostic message for "missing implementation.."
• indent
• testing

Quick questions

• Any thoughts on "title" (which is "Implement All Bar" for now in the screen-record below)
• Is it ok to return WorkspaceEdit instead of "Command"?
  
  
  
  • code action can return Command instead of edits, and it might be better to return command concerning the performance(because we can calculate the edit lazily).
  
  

Thank you so much for working on these PRs https://github.com/scalameta/metals/pull/1031 and https://github.com/scalameta/metals/pull/1065 @ckipp01 @gabro ! 👍
I could follow those implementations and re-use a lot of logic!

[olafurpg]

Looks amazing @tanishiking !

Any thoughts on "title" (which is "Implement All Bar" for now in the screen-record below)

I would try to use similar language as IntelliJ

Is it ok to return WorkspaceEdit instead of "Command"?

I think it's better to return a command if it's not too much work. iirc, some editor clients don't support support yet code actions that return edits 🤔

[olafurpg]

I'm really looking forward to use this feature! 😁 Since we added code actions to insert imports I've found myself trying to fix this error by muscle memory only to be sad realizing it's not implemented yet 😅

[gabro]

Wow, that looks great! 😍

In general I think it’s fine to return a workspace edit:

• I haven’t yet found a client that doesn’t support workspace edits (I may be wrong I’ll check again)
• performance wise this is the same as the analogous completion so we’re ok, I think

Quick question: are you also handling the case in which some methods are implemented and some others are not?

[tanishiking]

Thank you for quick feedback @olafurpg @gabro 😄
I'm also looking for this feature! (because I usually write TypeScript at work and I got used to implementing all missing methods in this way (code action)).

---

I would try to use similar language as IntelliJ

Sounds good!

I think it's better to return a command if it's not too much work. iirc, some editor clients don't support support yet code actions that return edits 🤔
I haven’t yet found a client that doesn’t support workspace edits (I may be wrong I’ll check again)
performance wise this is the same as the analogous completion so we’re ok, I think

OK, I'll go with the edit for the first implementation! (I'll also check some LSP clients).

are you also handling the case in which some methods are implemented and some others are not?

Yes:+1: But there could be some problems in the more complex cases (especially around a range of TextEdit), I'm gonna test in various situations.

[tgodzik]

Closed in https://github.com/scalameta/metals/pull/1379