ink! Analyzer: Retroactive funding for ink! 4.x to 5.0 migration features, and other major improvements (56,750 USDT)

Hello, I'm David Semakula (@davidsemakula) - the creator of ink! analyzer.

This is a follow-up proposal to #619: ink! Analyzer: Retroactive funding for ink! v5 support.
So, if you've already read #619, you can skip ahead to the "Proposal Ask" section, as the updated number of unique installs for the Visual Studio Code extension (now ~415 compared ~350 in #619) is the only meaningful difference in the introductory sections.
Additionally, be sure to also check out the "Previous Funding" section for more context about scope differences, and timing of the proposals and related ink! analyzer feature releases.

What's ink! analyzer?

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

In short, ink! analyzer is to ink!, what rust-analyzer is to Rust.

More technically, rust-analyzer is a Rust compiler frontend/semantic analyzer for IDEs that's built on
a lossless and resilient parser (this part is very important for IDE/editor tooling because the program is essentially perpetually incorrect as you type in an IDE/editor). So rust-analyzer "understands" core Rust language concepts (e.g. that a trait implementation like impl MyTrait for MyStruct {} must define all the required associated items of the trait), and provides intelligent editing features to help you with those kinds of core Rust language features.

However, when it comes to Rust syntax extensions/DSLs like ink!'s attribute macros,
when you annotate a mod item with #[ink::contract], all rust-analyzer "knows" is that this is a custom attribute, it doesn't "know" that an ink! contract mod must have exactly one struct item annotated with #[ink(storage)] or any of the other semantic rules for ink! contracts, so this is where ink! analyzer comes in 🙂.

For a deeper dive on the problems ink! analyzer solves and technical details about its architecture, check out this detailed introductory blog post.
You can also check out this awesome X/Twitter thread by the ink! lang team for a quick walkthrough of ink! analyzer features.

Adoption

ink! analyzer's most user/developer facing component is currently a Visual Studio Code extension, which has over ~415 unique installs (first released in Aug/2023).

However, ink! analyzer is built with an IDE/editor agnostic architecture to maximize re-usability of it's core components i.e.

A modular domain-specific semantic analysis library for ink! built on a resilient and lossless parser.
A Language Server Protocol (LSP) implementation built on top of the aforementioned semantic analysis library.

Figure 1: ink! Analyzer - LSP based Architecture Diagram

These two components (i.e. the semantic analyzer and language server) 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, these include Visual Studio Code, Visual Studio, Vim / Neovim, Emacs, Atom, Sublime Text, Acme, Lapce, Eclipse and many more.

Therefore, ink! analyzer 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).

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 (or installed/updated) by the extension/plugin/integration.
The Visual Studio Code extension serves as a showcase and reference implementation for this use case/approach.

However, ink! analyzer also distributes compiled ink! Language Server (ink-lsp-server) binaries for most of the major platforms/architectures for non-VS Code users and developers.

NOTE: While the first version of the ink! analyzer VS Code extension was released in Aug/2023, work on the core components (i.e. semantic analyzer and language server) started well before in Mar/2023.

Proposal Ask

This treasury proposal requests retroactive funding for adding ink! 4.x to 5.0 migration features, along with other major improvements, to ink! analyzer.

Requested Amount: $56,750 (in USDT on AssetHub - learn more here, here and here)

Breakdown/Tasks	Hours
ink! 4.x to 5.0 attribute-based entity migrations Events 2.0 migration Chain extension attribute macro and associated `fn` attribute argument migrations SCALE codec traits `derive` migration E2E test attribute and argument migration Unit tests	~108
ink! 4.x to 5.0 e2e `Client` and `MessageBuilder` API migrations New "builder" APIs and `ContractsBackend` trait for `instantiate`, `instantiate_dry_run`, `call`, `call_dry_run`, `upload` e.t.c New `ChainBackend` trait for `create_and_fund_account`, `balance`, `runtime_call` e.t.c Update e2e tests `fn` signature to include new `E2EBackend` trait Replace deprecated `build_message` fn, `MessageBuilder` type, and related `call` callback with new API equivalents Remove ink! e2e deprecated imports i.e. `build_message`, `MessageBuilder` e.t.c Unit tests	~196
ink! 4.x to 5.0 semantics-preserving cross-contract host function related API migrations Replace `call` from `CallBuilder` via `build_call` with `call_v1` Add an `instantiate_v1` call before other method calls on `CreateBuilder`s via `build_create` Replace `instantiate_contract` and `invoke_contract` with `instantiate_contract_v1` and `invoke_contract_v1` for direct calls in any function Replace `instantiate_contract` and `invoke_contract` with `instantiate_contract_v1` and `invoke_contract_v1` for indirect calls via `Self::env()` and `self.env()` in constructors and messages Replace `Call` constructors with `CallV1` Unit tests	~156
ink! 4.x to 5.0 migration command and code action, and `Cargo.toml` migration `Cargo.toml` migration Replace references to `SCALE` codec items with equivalent `ink` re-exports Command and code action for performing migration (across semantic analyzer, language server and VS Code extension) Unit tests	~124
General ink! 5.0 additions and improvements Support for ink! workspace dependencies Command and code action for extracting events into standalone packages (across semantic analyzer, language server and VS Code extension) Completions and code actions for ink! combine extensions declarative macro Unit tests	~132
General robustness and feature improvements Update completions to support inserting full ink! entities (i.e. full Rust items not just ink! attribute macros and arguments e.g. ink! constructor and message `fn` items as completions when typing `fn` inside `impl` blocks e.t.c) Improve item resolution utilities (e.g. add ability to resolve imports in function items) Improve interface for traversing ink! attribute argument meta-items Performance improvements (e.g. removing needless eager evaluation) Unit tests	~144
Integration tests (across semantic analyzer, language server and VS Code extension)	~40
Documentation	~8
Total Hours	~908
Hourly Rate	$62.5
Total Amount	$56,750

NOTE: All ink! analyzer components are fully open-source and distributed under OSI approved licenses.

Previous Funding

Previous work for ink! analyzer was funded by two generous Web3 Foundation technical grants, and one retroactive treasury proposal.

https://github.com/w3f/Grants-Program/blob/master/applications/ink-analyzer.md ($30,000)
https://github.com/w3f/Grants-Program/blob/master/applications/ink-analyzer-phase-2.md ($59,600)
https://polkadot.subsquare.io/referenda/619 (2,812.27 DOT/ ~$26,500 on 27/Mar/2024)

However, with the project now relatively mature and having some meaningful adoption, I've moved to a retroactive treasury funding model for future updates.

NOTE: The previous "v5 support" retroactive treasury proposal only included ink! v5 support, while this proposal is mainly focused on ink! v4 to v5 migration features, but also includes a few other major improvements (e.g. support for ink! workspace dependencies, and a major update to completions infrastructure, that enables support for full ink! entity completions, to complement the already existing support for ink! attribute macro and argument completions - see breakdown above for details and/or check out this blog post).
Lastly, similar to the previous "v5 support" retroactive treasury proposal, work on these features in ink! analyzer started well before the official ink! v5 release (13/Mar/2024), however, these features still "needed some polish" during the initial release for ink! v5 support in ink! analyzer (16/Mar/2024 - see also), and so were excluded from both the initial release and the previous "v5 support" retroactive treasury proposal (27/Mar/2024).

Why not Wasm Smart Contracts Bounty / ink!ubator ?

Historically, as noted above, initial work for ink! analyzer was funded by Web3 Foundation technical grants.
This is partly because development of ink! analyzer kicked off in Mar/2023, while the ink!ubator: Ecosystem Grants program only started receiving grant applications around ~May/2023 (note that discussions for the Wasm Smart Contracts Bounty started well before this though).

In the present, with ink!ubator being an incubation program following a cohort schedule, and ink! analyzer now being a relatively mature project with some meaningful adoption, the need to support new ink! features and syntax as close to release as possible (hence the choice of retroactive funding), means the ink!ubator cohort schedule is not a good fit for this stage of the project.

More about the author.

I'm an independent Software Engineer & Systems Architect with over 10+ years of experience.

I also independently contribute to rust-analyzer (a Rust compiler front-end for IDEs).

I've also made some independent contributions to ink!.