While reviewing CL 787541 and reviewing previous CL regarding tags removal code action, we found this missing feature from interactive refactoring.
gopls version
v0.22.1
go env
What did you do?
Trigger code action "gopls.implement_interface", this code action stub methods to the type to satisfy an interface.
What did you see happen?
However, if the interface is a generic (contains free type parameters), the code action will fail.
What did you expect to see?
Instead, gopls should dynamically ask follow up questions,
Questions: []{
{id: "interface"}
}
Answers: []{
{id: "interface", value: "foo.GenericInterface"}
}
Questions: []{
{id: "interface"}
{id: "type0"}
{id: "type1"}
}
Answers: []{
{id: "interface", value: "foo.GenericInterface"}
{id: "type0", value: "foo.Type0"}
{id: "type1", value: "foo.Type1"}
}
Then gopls can generate the proper methods stub for the user.
The scenario above is dynamically generating new question based on the previous answers, and the tags removal code action is dynamically generating questions based on the current context (like the position of the file).
While reviewing CL 787541 and reviewing previous CL regarding tags removal code action, we found this missing feature from interactive refactoring.
gopls version
v0.22.1
go env
What did you do?
Trigger code action "gopls.implement_interface", this code action stub methods to the type to satisfy an interface.
What did you see happen?
However, if the interface is a generic (contains free type parameters), the code action will fail.
What did you expect to see?
Instead, gopls should dynamically ask follow up questions,
Then gopls can generate the proper methods stub for the user.
The scenario above is dynamically generating new question based on the previous answers, and the tags removal code action is dynamically generating questions based on the current context (like the position of the file).