Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: ParseExported mode and go/analysis #35089

Open
stamblerre opened this issue Oct 22, 2019 · 2 comments
Assignees
Labels
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 22, 2019

go/analysis requires code from source in order to get facts for all dependencies.
Our current strategy of parsing dependencies in exported mode deletes function bodies, thereby preventing go/analysis from getting correct facts for dependencies.

Some possible solutions:

  • Parse dependencies in full mode
    • Will fix everything easily
    • Takes up a lot of memory
  • Parse dependencies in full mode, run analyses, trim ASTs, and re-cache as ParseExported
    • This will be hard to get right
    • This will require deleting items from the cache explicitly
    • It may throw off position information
    • This will still keep a lot of unnecessary information around in the *types.Info map
  • Have a separate path for type-checking language features like completion, definition, etc. and analysis.
    • Language feature path: Type-checks only a specific function in a package as well as the package's dependencies in exported form
    • Analysis path: Type-checks everything from source, caching only analysis facts

/cc @ianthehat @dominikh @muirrn

@gopherbot gopherbot added this to the Unreleased milestone Oct 22, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 22, 2019

Change https://golang.org/cl/202623 mentions this issue: internal/lsp: use source.ParseFull for all AST parsing

@muirdm

This comment has been minimized.

Copy link

@muirdm muirdm commented Oct 22, 2019

Maybe a wacky idea, but has anyone ever thought about "compressing" the type info? In my experience, a lot of the memory usage is from map overhead for all the AST overlay maps in *types.Info. Maybe we could compress the *types.Info data down into slice form when not being used to save space. The assumption is that thawing the data would still be much faster than re-type checking the package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.