Single-pass hover text extraction #66
Conversation
|
Drive by comment: I'm unsure how applicable this package is, but it might be a nice performant architecture for writing things which extract information from go. https://godoc.org/golang.org/x/tools/go/analysis |
|
@keegancsmith this would be useful to report diagnostics but wouldn't replace any work here. |
Should probably fork this into another discussion, but take a closer look at that package. It is a generic way to build tools which extract information from go programs in efficient ways. IE takes care of things like caching intermediate artefacts based on the build graph. However, given we don't really have a good way to do incremental work for |
There was a problem hiding this comment.
The index function is over 100 lines of code and invokes multiple loops and processes and there are no tests to determine the logic in that function is working as expected all cases. Please add tests for the core index function so we can validate that these logic changes aren't breaking.
The current implementation of lsif-go contains a super-quadratic way of determining comments based on token positions. For each definition, we trace the AST from the root of the containing file through nodes that intersect the target position (via
astutil.PathEnclosingInterval) then extract the comments by tracing the constructed ancestor path backwards.This requires us to scan the same file from the root for every definition that exists in that file. Much of this work will be repeated and we'll end up tracing the same path multiple times to get to definitions with slightly different paths. Tell me that's not a bad idea in a world containing files of this size.
This change introduces a pre-warmed cache of hover text that is extracted by traversing the AST of each file once. We further speed up this process by walking GOMAXPROC files in parallel.