Closed digitallyserviced closed 1 year ago
Thanks for the bug report.
Note to us: the logic responsible for the bug is here, where it assumes the insertion point is the End
of the syntax node that is the parent (nodes[1]
) of the TypeName object (si.Concrete.Obj
). But of course this is only the end of a TypeSpec within a parenthesized group.
Change https://go.dev/cl/456316 mentions this issue: gopls/internal/lsp/source: emit interface stub methods at top level
oh wow, haven't been keeping up with my notifications. I wanted to make sure I updated this and made it known that I appreciate it's attention and all con7r's of gopls and go general... you guys rock!
@adonovan... thanks for your effort to resolve, especially since you had to deal with fixing tests... That is 11x more effort than I would have put in for tests if the bug had been fixed lol
gopls version
go env
What did you do?
Wrote some code that I then wanted to generate stubs for a struct to impl an interface.
What did you expect to see?
B
onA
with the methods inserted AFTER the type() closure. I actually assumed this would create methods after the current closure i happen to be in that is part global package scope. Then because the methods are inserted right next to where my cursor/file i am viewing is, I can cut/copy them to where I need.What did you see instead?
When accepting to run the code action for implementing method stubs for the interface it fails with an error similar to.... Which is very confusing and makes no real mention or reference to the problem. Especially since we're not in a
func
or have one at the referenced line.gopls: 0: could not reparse file: main:#LINENO:1: expected 'IDENT', found 'func' (and #ERRS more errors)
with the #LINENO referencing the line after the type definition for the struct
(A)
we are trying to generate stubs for.There is also no file name listed.
If you have multiple files in the same package and the struct is in another file this error is useless.The #ERRS I am unsure of what additional issues it is complaining about, but irrelevant to the issue/solution.
Simply moving the type definition for the struct we want to generate stub methods for outside of the type() closure resolves the issue. It would seem the stubs are generated under the struct's definition expecting them to be in the global/outside any closure.
Editor and settings
Neovim v0.9.0-dev All analyses and hints enabled through gopls.
Logs
THX U! I have struggled with this error for months only having recently spent a few hours to investigate why some types wouldn't work with this.