Skip to main content

ink! Analyzer (Phase 2)

  • Team Name: David Semakula
  • Payment Address: 0x5c1D926f62B61C9cf62167474111385ff7393c61 (USDC)
  • Level: 3

Project Overview 📄​

This application is for a follow-up grant for ink! Analyzer.

Overview​

ink! analyzer is a collection of modular and reusable libraries and tools for semantic analysis of ink! smart contract code.

Objective​

ink! analyzer aims to improve ink! language support in integrated development environments (IDEs), source code editors and other development tools by providing modular and reusable building blocks for implementing language features (e.g. diagnostic errors, quick fixes, code completion suggestions, code/intent actions and hover content e.t.c) for the ink! programming language which is used for writing smart contracts for blockchains built on Substrate.

Problem​

ink! is an Embedded Domain Specific Language (eDSL) that you can use to write WebAssembly based smart contracts in the Rust programming language. In fact, "ink! is just standard Rust in a well-defined "contract format" with specialized #[ink(…)] attribute macros".

This allows ink! developers to leverage Rust tooling like clippy, cargo, crates.io and excellent IDE/code editor support via rust-analyzer and IntelliJ Rust.

However, relying on only generic Rust language support in IDEs, code editors and other development tools has some significant limitations for the developer experience including:

Solution​

To solve the above challenges and improve ink! language support in IDEs, code editors and other development tools, ink! analyzer created two main components:

These two components can be reused to add ink! language support to multiple IDEs, code editors and other development tools.

In particular, a large number of IDEs and code editors support LSP servers either via configurable LSP clients or robust LSP client libraries/APIs/modules, including Visual Studio Code, Visual Studio, Vim / Neovim, Emacs, Atom, Sublime Text, Acme, Lapce, Eclipse and many more.

This project makes it relatively easy for:

  • Users to enable ink! language support for their IDE, code editor or other development tool if it has either a native/built-in or third-party LSP client that can be configured to launch an LSP server using an executable command (i.e. the path to an installed ink! Language Server binary) and can use stdio (standard in/standard out) as the message transport.
  • Developers to either build extensions/plugins/integrations that add ink! language support to any tool with robust LSP client libraries/APIs/modules, or add first-class ink! language support to an existing LSP client (e.g. an open-source extension/plugin/integration).

In addition to distributing compiled ink! Language Server (ink-lsp-server) binaries for a few platforms, ink! analyzer additionally distributes a Visual Studio Code extension that ships with a bundled ink! Language Server as a showcase and reference implementation for the latter use case.

The latter option typically provides a better user experience as the user doesn't have to manually install (and update) the ink! Language Server as it can be bundled by the extension/plugin/integration.

For IDEs, code editors and other development tools that don't have robust LSP client libraries/APIs/modules, extensions/plugins/integrations can either implement their own LSP client middleware or use the semantic analyzer directly.

This stage of the project will improve ink! language support features across all components by adding:

  • Quick fixes for all existing diagnostic errors and warnings.
  • ink_e2e macro support (i.e diagnostics, quickfixes, completions, code actions and hover content).
  • Command for creating an ink! project and code/intent actions for inserting code stubs/snippets for relevant ink! entities.
  • Inlay hints and signature help/parameter hints for ink! attribute arguments.
  • Code/intent actions for "flattening" ink! attributes.
  • Diagnostics that verify that the value of env values for #[ink::contract] and environment values for #[ink_e2e::test] are impl Environment as well as quick fixes to impl Environment for the target item where necessary.
  • Diagnostics that verify chain extension ErrorCode types (and other chain extension utility types) implement required traits (e.g. FromStatusCode for ErrorCode types and SCALE code traits - i.e. scale's Encode and Decode and scale-info's TypeInfo traits - for error types, and input and output types of chain extension methods) as well as quick fixes to implement the required traits for the target items where necessary.
  • Diagnostics and quickfixes for implementing missing methods for ink! trait definition implementations.

Observation​

In the context of smart contracts and the blockchain ecosystem, static code analysis tends to be closely associated with security and vulnerability detection. This project uses the narrower term "semantic analysis" because its primary goal (at this stage) is to improve ink! language support in IDEs, code editors and other development tools. Therefore, for now, ink! analyzer will not provide any features related to security and vulnerability detection. However, such functionality will be added in the future.

Project Details​

Architecture Diagram​

ink! Analyzer - LSP based Architecture Diagram Figure 1: ink! Analyzer - LSP based Architecture Diagram

Architecture Components​

1. Semantic Analyzer​

The semantic analyzer is responsible for parsing the smart contract code, analyzing it based on ink!'s semantic rules for smart contracts and returning semantic information for other components to consume.

It is written in Rust and uses rust-analyzer's ra_ap_syntax crate for generating the syntax tree of the smart contract code that it analyzes.

It uses ra_ap_syntax instead of other Rust parsing and syntax tree libraries because ink! analyzer has similar design goals to rust-analyzer. The most important being that parsing should be:

  • resilient (even if the input is invalid, parser tries to see as much syntax tree fragments in the input as it can).
  • lossless (even if the input is invalid, the tree produced by the parser represents it exactly).

As a concrete example, while ink!'s ink_ir crate includes syntax tree and intermediate representation (IR) modules, it uses syn as its parser. Syn however, (being "geared toward use in Rust procedural macros") assumes "that all input to it is well-formed". So for the ink!/Rust code snippet below that contains only one invalid line, syn simply returns an error while ra_ap_syntax still generates a lossless syntax tree with errors represented by "error nodes", thus allowing analysis to still be performed on the rest of the valid code.

#[ink::contract]
mod flipper {

    #[ink(storage)]
    pub struct Flipper {
        value: bool,
    }

    bad statement; // This is an invalid line
}

This makes syn (and by extension ink!'s ink_ir crate) unsuitable for our IDE/code editor use case.

2. Language Server​

The language server implements the Language Server Protocol (LSP) and acts as a backend that provides language support features like diagnostic errors, code completion suggestions, code/intent actions and hover content to IDEs, code editors and other development tools. It uses the semantic analyzer as the engine for providing ink! language support features by:

  • translating LSP requests into semantic analyzer interface calls.
  • translating semantic analysis results into corresponding LSP types.

It can be reused by multiple IDEs, code editors and other development tools that support LSP servers either via native/built-in LSP clients or third-party LSP client extensions/plugins/integrations.

It is written in Rust and uses:

  • rust-analyzer's lsp-server crate to handle LSP protocol handshaking and parsing messages
  • the lsp-types crate for LSP type definitions.
3. Extension/Plugin/Integration​

Extensions/plugins/integrations add ink! language support to a specific IDE, code editor or development tool by communicating with the language server running as a separate process using the Language Server Protocol via JSON-RPC.

Only a VS Code extension is currently implemented. The VS Code extension is written in TypeScript using VS Code's extension API and language server client library.

Technology Stack​

Rust - is used for implementing the semantic analyzer and language server components.

TypeScript - is used for implementing the VS Code extension.

Ecosystem Fit​

This project provides building blocks for improving ink! language support in IDEs, code editors and other development tools thus improving the developer experience for ink! smart contract developers. It additionally already implements an extension for VS Code, one of the most popular code editors for developers, that also serves as a showcase and reference implementation for using ink! analyzer components to add ink! language support to IDEs and code editors with robust LSP client libraries/APIs/modules.

I'm not currently aware of any similar projects in the Substrate / Polkadot / Kusama ecosystem. However, for Solidity and the Ethereum ecosystem, there are:

Team 👥​

Team members​

Contact​

I'll be working as an individual.

  • Registered Address: N/A
  • Registered Legal Entity: N/A

Team's experience​

I'm an independent Software Engineer & Systems Architect with over 10 years of experience. I've worked as a technical lead on projects for HubSpot, Permobil, Pressboard, Grindery, InboundLabs, Tunga, ButterflyWorks, Telegraaf Media Groep (TMG) and many more companies. I hold a Bachelor of Science in Computer Science degree from Makerere University, Kampala, Uganda. You can find my full profile at https://davidsemakula.com.

Team Code Repos​

Team LinkedIn Profiles (if available)​

Development Status 📖​

I've delivered implementations of the semantic analyzer, language server and VS Code extension in the first W3F grant application for this project:

The VS Code extension is published in the VS Code Marketplace at https://marketplace.visualstudio.com/items?itemName=ink-analyzer.ink-analyzer.

ink! analyzer has also been added to the official ink! documentation portal at https://use.ink/getting-started/ink-analyzer (under "Third Party Tools and Libraries").

You can find a full list of available resources in the introductory blog post for ink! analyzer.

Development Roadmap 🔩​

Overview​

  • Total Estimated Duration: ~8.5 months
  • Full-Time Equivalent (FTE): 1
  • Total Costs: 59,600 USD

Milestone 1 — Semantic analyzer: Quick fixes, ink_e2e macro support, project creation command and code/intent actions for inserting code stubs/snippets for relevant ink! entities​

  • Estimated duration: ~5-6 weeks
  • FTE: 1
  • Costs: 10,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust crate update: Quick fixes for all existing diagnostic errors and warningsI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return quick fixes (suggested edits/code actions) for all existing diagnostics. I will leverage the existing methodology for extracting ink! semantic rules that was used to extract the existing (more than 74) diagnostics errors and warnings to determine the relevant quick fix(es) for each diagnostic based on the related semantic rules and context. The high-level methodology can be summarized as: 1) remove and/or replace ink! attribute for ink! attributes applied to the wrong Rust item (e.g. for #[ink(storage)] attribute applied to anything other than a struct, a quick fix to remove the ink! attribute and another to add a relevant ink! attribute, e.g #[ink::contract] if the original attribute was applied to a mod and no other ink! contracts are defined in the current file e.t.c) 2) remove and/or add/replace Rust invariants for ink! entities that don't satisfy ink! semantic rules based on expected Rust item invariants (e.g. add a self reference - i.e. &self or &mut self - to an #[ink(message)] whose fn item's parameters don't include a self reference, or remove a self reference from an #[ink(constructor) whose fn item's parameters include a self reference, or rename the associated type for a chain extension to ErrorCode if no other associated type named ErrorCode exists e.t.c) 3) move ink! entities to the appropriate "scope" (e.g. move ink! constructors and ink! messages implemented in the root of the ink! contract module to either the first non-trait impl block or create a new impl block to for them e.t.c). 4) update order of ink! attributes so that the "primary" attribute comes first (e.g. refactor #[ink(payable)]\n#[ink(message)] to #[ink(message)]\n#[ink(message)] or #[ink(anonymous, event)] to #[ink(event, anonymous)] e.t.c). This methodology should not be considered exhaustive at this point as more patterns may be found during actual implementation, in which case, they will be documented.
2.Rust crate update: ink_e2e macro supportI will update the semantic analyzer crate to return diagnostics, quickfixes, completions, code/intent actions and hover content for the ink_e2e macro via the existing interfaces for all the aforementioned features. Diagnostics and quick fixes will be extracted using the existing methodology for extracting ink! semantic rules with the difference being the use of the ink_e2e_macro crate (instead of the ink_macro crate) as the entry point. Completions, code/intent actions (for adding the attribute macro and/or attribute arguments) and hover content will be added for the #[ink_e2e::test] macro as well as its associated attribute arguments (i.e. additional_contracts, environment and keep_attr).
3.Rust crate update: Command for creating a new ink! project with a contract stubI will update the semantic analyzer crate to provide an interface that accepts a name as input and returns an ink! smart contract code stub/snippet similar to those created by cargo contract new.
4.Rust crate update: Code/intent actions for inserting code stubs/snippets for relevant ink! entitiesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code/intent actions for inserting code stubs/snippets for relevant ink! entities for the current context (e.g. in the context of the root of an ink! contract mod, code actions for inserting ink! storage - if an ink! storage struct isn't already defined - and/or ink! event code stubs/snippets which would wrap an edit that adds a struct annotated with the relevant ink! attribute e.g #[ink(event)] e.t.c). This applies to all ink! entities (i.e. contract, storage, constructor, message, event, trait definition, chain extension, storage item e.t.c.) that would be relevant for any given context - context being determined by the parent/ancestor ink! attribute annotations for the current cursor position.

Milestone 2 — Semantic Analyzer: Inlay hints, signature help/parameter hints and attribute "flattening"​

  • Estimated duration: ~3-4 weeks
  • FTE: 1
  • Costs: 6,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust crate update: Inlay hints for ink! attribute argument valuesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code as input and returns inlay hints for ink! attribute argument values (e.g. u32 | _ for selector values, u32 for extension values, &str (a valid Rust identifier for) for namespace values, &str (a comma separated list) for keep_attr values, Path for env and environment values e.t.c). Inlay hints will be provided for all ink! attribute arguments that require values (i.e env, keep_attr, namespace, selector, extension, handle_status, derive, additional_contracts, environment e.t.c).
2.Rust crate update: Signature help/parameter hints for ink! attribute argumentsI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns signature help/ parameter hints for relevant ink! attribute arguments. Signature help/parameter hints will be provided for all ink! attribute macros with associated ink! attribute arguments (e.g. env and keep_attr for #[ink::contract()], namespace and keep_attr for #[ink::trait_definition()], derive for #[ink::storage_item()] e.t.c) and "primary" ink! attribute arguments that can be combined with other ink! attribute arguments (e.g. anonymous for #[ink(event)], payable, selector and default for #[ink(message)], selector and default for #[ink(constructor)], handle_status for #[ink(extension)] e.t.c).
3.Rust crate update: Code/intent actions for "flattening" ink! attributesI will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns code/intent actions for "flattening" relevant ink! attributes and arguments (e.g. converting #[ink(event)]\n#[ink(anonymous)] to #[ink(event, anonymous)], or #[ink(message)]\n#[ink(payable)]\n#[ink(selector = 1)] to #[ink(message, payable, selector = 1)] e.t.c). "Flattening" will be supported for all ink! attribute arguments that can be combined to form "compound" ink! attributes (e.g. event and anonymous for ink! events, message, payable, default and selector for ink! messages, impl and namespace for ink! impl, extension and handle_status for ink! extensions e.t.c) and for erroneously split ink! attribute macros and there associated arguments (e.g. converting #[ink::contract]\n#[ink(env=crate::Environment)]\n#[ink(keep_attr="foo, bar")] to #[ink::contract(env=crate::Environment, keep_attr="foo, bar")] e.t.c).

Milestone 3 — Semantic Analyzer: Go to definition, find references and rename/refactor support for path-based ink! attribute argument values and diagnostics, quick fixes and code/intent actions ink! attribute argument values that should impl Environment​

  • Estimated duration: ~5-6 weeks
  • FTE: 1
  • Costs: 10,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust crate update: Diagnostics that verify resolution of path expressions for env for #[ink::contract] and environment for #[ink_e2e::test] argument values as well as quick fixes that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible)I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for resolution of path expressions for env for #[ink::contract] and environment for #[ink_e2e::test] argument values whose value doesn't resolve to any item as well as quick fixes in the form of code/intent actions that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible).
2.Rust crate update: Diagnostics that verify that env values for #[ink::contract] and environment values for #[ink_e2e::test] are impl Environment as well as quick fixes to impl Environment for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for env values for #[ink::contract] and environment values for #[ink_e2e::test] whose target item doesn't impl Environment as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that impl Environment for the target item where necessary.
3.Rust crate update: Diagnostics that verify that ink! trait definition impl blocks implement all associated methods as well as quick fixes for implementing missing methods where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for ink! trait definition impl blocks that don't implement all associated methods as well as quick fixes in the form of code/intent actions that add code stubs/snippets for implementing missing methods where necessary.

Milestone 4 — Semantic Analyzer: Diagnostics, quick fixes and code/intent actions for chain extension ErrorCode type is impl FromStatusCode , and is not referred to using Self::ErrorCode anywhere in the chain extension or its defined methods​

  • Estimated duration: ~5-6 weeks
  • FTE: 1
  • Costs: 10,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust crate update: Diagnostics that verify that the chain extension ErrorCode type is impl FromStatusCode as well as quick fixes and code/intent actions to impl FromStatusCode for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension ErrorCode types whose target item doesn't impl FromStatusCode as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that impl FromStatusCode for the target item where necessary.
2.Rust crate update: Diagnostics for references to the chain extension's ErrorCode type using Self::ErrorCode in the chain extension (i.e. the #[ink::chain_extension] annotated trait) or it's defined methods (i.e. impl blocks for the chain extension trait in a #[ink::contract] annotated mod) as well as quick fixes to replace Self::ErrorCode usages with the ErrorCode type directlyI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for references to the chain extension's ErrorCode type using Self::ErrorCode in the chain extension (i.e. the #[ink::chain_extension] annotated trait) or it's defined methods (i.e. impl blocks for the chain extension trait in a #[ink::contract] annotated mod) as well as quick fixes in the form of code/intent actions that replace Self::ErrorCode usages with the ErrorCode type directly.
3.Rust crate update: Diagnostics that verify that the chain extension ErrorCode type implements SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension ErrorCode types whose target item doesn't implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target item where necessary.
4.Rust crate update: Diagnostics that verify that input and output types of chain extension methods implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessaryI will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for input and output types of chain extension methods whose target items don't implement SCALE codec traits (i.e. scale's Encode and Decode and scale-info's TypeInfo) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target items where necessary.

Milestone 5 — Language Server: Updates #1​

  • Estimated duration: ~3-4 weeks
  • FTE: 1
  • Costs: 6,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the crate, instructions for installing and using the crate and links to other documentation and resources related to the crate.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust binary crate update: ink! Language Server updatesI will update Rust binary crate that implements the Language Server Protocol to support features added to the semantic analyzer in milestones 1 and 2 above.

Milestone 6 — Language Server: Updates #2​

  • Estimated duration: ~3-4 weeks
  • FTE: 1
  • Costs: 6,800 USD
NumberDeliverableSpecification
0a.LicenseMIT or Apache 2.0
0b.DocumentationI will provide detailed source documentation including rustdoc documentation that will be published to docs.rs and a README file (published on Github, crates.io and docs.rs) providing general information about the crate, instructions for installing and using the crate and links to other documentation and resources related to the crate.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
1.Rust binary crate update: ink! Language Server updatesI will update Rust binary crate that implements the Language Server Protocol to support features added to the semantic analyzer in milestones 3 and 4 above.

Milestone 7 — Visual Studio Code Extension: Updates​

  • Estimated duration: ~3-4 weeks
  • FTE: 1
  • Costs: 6,800 USD
NumberDeliverableSpecification
0a.LicenseGPL-3.0
0b.DocumentationI will provide inline source documentation and a README file (published on Github and the VS Code marketplace) providing general information about the extension, instructions for installing and using the extension and links to other documentation and resources related to the extension.
0c.Testing and Testing GuideCore functions will be fully covered by comprehensive integration tests to ensure functionality and robustness. In the guide, I will describe how to run these tests.
0d.DockerI will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.ArticleI will publish an article that introduces the new features of ink! analyzer, including updates to the VS Code extension, the language server and the semantic analyzer.
1.Visual Studio Code Extension: UpdatesI will update the Visual Studio Code Extension to support the ink! language support features added to the language server and semantic analyzer in milestones 1, 2, 3, 4, 5 and 6 above. Visual interface demos of all the IDE/editor features can be found in VS Code extension documentation for diagnostics, completions, hover content, code actions, quick fixes, signature help/parameter hints (demo uses functions but should still be helpful for interface visualization for ink! attribute arguments), inlay hints, go to definition, find references, rename/refactor, snippets/code stubs and commands.

Future Plans​

I will publish updates to the VS Code extension to the VS Code marketplace.

In the short-term, I will likely apply for follow-up funding for:

  • adding an IntelliJ platform plugin.
  • adding security and vulnerability detection related static code analysis.
  • adding more features and maintaining existing components.
  • adding new reusable components for tools that don't support LSP.

As the project is a public good, the long-term goal is to create a community of users, contributors and ecosystem partners who are invested in the project's long-term success because of its utility.

Referral Program (optional) 💰​

N/A

Additional Information ➕​

How did you hear about the Grants Program?

Web3 Foundation Website.