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.
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.
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.
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:
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.
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
|
~108 |
ink! 4.x to 5.0 e2e Client and MessageBuilder API migrations
|
~196 |
ink! 4.x to 5.0 semantics-preserving cross-contract host function related API migrations
|
~156 |
ink! 4.x to 5.0 migration command and code action, and Cargo.toml migration
|
~124 |
General ink! 5.0 additions and improvements
|
~132 |
General robustness and feature improvements
|
~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 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).
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.
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.
Threshold
Big thank you to everyone who supported this proposal! ๐