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

[pipedream] add type infromation to ast-grep with LSIF #433

Open
HerringtonDarkholme opened this issue May 30, 2023 · 1 comment
Open

[pipedream] add type infromation to ast-grep with LSIF #433

HerringtonDarkholme opened this issue May 30, 2023 · 1 comment
Labels
help wanted Extra attention is needed wontfix This will not be worked on

Comments

@HerringtonDarkholme
Copy link
Member

HerringtonDarkholme commented May 30, 2023

a value’s type at a certain position is available if we have Language Server Index Format!
Maybe we can add this to meta variable constraints.....
https://comby.dev/blog/2022/08/31/comby-with-types

@HerringtonDarkholme HerringtonDarkholme added help wanted Extra attention is needed wontfix This will not be worked on labels May 30, 2023
@0xdevalias
Copy link

0xdevalias commented Dec 4, 2023

Summarising some of the key points from the above blog for easier reference:

  • https://comby.dev/blog/2022/08/31/comby-with-types
    • To that end, I really just want comby to use an external service that answers: What is the type of the value at this location in the file?

      Type-information-as-a-service is ideal because then I can keep the convenience of matching syntax easily, and outsource accessing language-specific semantic properties as needed. The concept is to expose a property on any matched variable that corresponds to type information (if available).

    • I know of only two high-level solutions resembling a service that conveniently provides type information today, and which aim to eventually support all languages. The first is language server implementations of LSP (Language Server Protocol). Language servers expose all kinds of information, and typically include type information in hover tooltips found in editors. With LSP there is no authoritative, centralized language server that you can just query. Instead, language servers are configured for specific projects and either run locally on your machine or get managed by an organization.

      The second is a central, public-facing service maintained on Sourcegraph.com that exposes hover information similar to the LSP format (disclaimer: I work at Sourcegraph, but my day job is unrelated to this service). The key difference is that Sourcegraph automatically processes popular repositories on GitHub (currently about 45K) with support for TypeScript, Go, Java, Scala, and Kotlin. It’s also possible to process your own projects (locally, in CI, or GH actions) and upload the data. Once that happens, you can efficently browse or query type information for variables on hover.

      This is exactly the kind of information I need to tell whether a matched variable is a slice, map, channel, or pointer. For supported projects, you just fire a GQL request to get the hover content.

    • Which projects and languages does this work for?

      If a repository is processed with precise type-on-hover on Sourcegraph.com, accessing that information via comby should just work. This means you can use tools to process and upload this information with your own TypeScript, Java, Scala, Kotlin, or Go projects to Sourcegraph and comby will be able to access hover information for them. These tools encode type information and other data using SCIP, which is related to the Language Server Index Format (LSIF/LSP) but with efficiency in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants