Referendum #779

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

Executed

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.

ink! Analyzer - LSP based Architecture Diagram
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 CreateBuilders 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.

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!.

You can check out my GitHub profile and/or my personal website for more details.

Edited
Reply
Up
Share
Request
56,750
Status
Decision28d
Confirmation
2d
Attempts
1
Tally
100%Aye
50.0%Threshold
0%Nay
Aye
โ‰ˆ26.54MDOT
Nay
10DOT
  • 0.0%
  • 0.0%

    Threshold

  • 0.0%
Support
0.34%
โ‰ˆ4.9MDOT
Issuance
โ‰ˆ1.43BDOT
Votes
Nested
Flattened
Calls
Check how referenda works here.
Call
Metadata
Timeline6
Votes Bubble
Statistics
Comments
[Deleted Account]

Big thank you to everyone who supported this proposal! ๐Ÿ™‚

Reply
Up
[Deleted Account]

Calls.jpg

Reply
Up