Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Edit: I've narrowed the issue down further, see follow up comment below.
I'm seeing these two separate crashes on master (08e0b306e832746e6ccdb36ca8720cec1d3675e4).
I've narrowed it down to this repro involving build tags:
I tried in VSCode and it didn't seem to reproduce as easily, so here is me Emacs lsp debug log:
I've found the panics are not directly related to build tags. They happen when you have type checker error like having two functions of the same name. The crash is reproducible by defining the function "Foo" twice in one package, then opening another package that imports the first package.
In particular, one of the "Foo" methods has no type information since it is not valid, and some of the analyzers assume that *ast.FuncDecl nodes have type information.
The panic seems to have started after this change golang/tools@08bd53a. @stamblerre do you think this is a gopls bug and it shouldn't be invoking the analyzers, or should the analyzers not crash in this case?
Ah, I think my reasoning here was to sort of hide the problems caused by build tags, but of course it always comes back to build tags. Basically, you get false errors from packages with build tags, and then any package that imports those can't run analyzers because there are no results from the dependency packages. I guess the real solution here is to figure out how to handle build tags...