cf0ce14351
429: Reorganize hir public API in terms of code model r=matklad a=matklad Recently, I've been thinking about introducing "object orient code model" API for rust: a set of APIs with types like `Function`, `Module`, etc, with methods like `get_containing_declaration()`, `get_type()`, etc. Here's how a similar API might look like in .Net land: https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel?view=roslyn-dotnet https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.imethodsymbol?view=roslyn-dotnet The main feature of such API is that it can be powered by different backends. For example, one can imagine a backend based on salsa, and a backend which reads all the data from a specially prepared JSON file. The "OO" bit is interesting mostly in this "can swap implementations via dynamic dispatch" aspect, the actual API could have a more database/ECS flavored feeling. It's not clear at this moment how exactly should we implement such a dynamically (or if we even need dynamism in the first pace) swapable API in Rust, but I'd love to experiment with this a bit. For starters, I propose creating a `code_model_api` which contains various definition types and their public methods (mandatory implemented as one-liners, so that the API has a header-file feel). Specifically, I propose that each type is a wrapper around some integer ID, and that all methods of it accept a `&db` argument. The actual impl goes elsewhere: into the db queries or, absent a better place, into the `code_model_api_impl`. In the first commit, I've moved the simplest type, `Crate`, over to this pattern. I *think* that we, at least initially, will be used types from `code_model_api` *inside* `hir` as well, but this is not required: we might pick a different implementation down the line, while preserving the API. Long term I'd love to replace the `db: &impl HirDatabase` argument by a `mp: &dyn ModelProvider`, implement `ModelProvider` for `T: HirDatabase`, and move `code_model_api` into the separate crate, which does not depend on `hir`. @flodiebold you've recently done some `Def`s work, would do you think of this plan? Could it become a good API in the future, or is it just a useless boilerplate duplicating method signatures between `code_model_api` and `code_model_impl`? Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com> |
||
|---|---|---|
| .cargo | ||
| crates | ||
| editors | ||
| .gitignore | ||
| .travis.yml | ||
| ARCHITECTURE.md | ||
| bors.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| ROADMAP.md | ||
| rustfmt.toml | ||
Rust Analyzer
Rust Analyzer is an experimental modular compiler frontend for the Rust language, which aims to lay a foundation for excellent IDE support.
It doesn't implement much of compiler functionality yet, but the white-space preserving Rust parser works, and there are significant chunks of overall architecture (indexing, on-demand & lazy computation, snapshotable world view) in place. Some basic IDE functionality is provided via a language server.
Work on the Rust Analyzer is sponsored by
Quick Start
Rust analyzer builds on Rust >= 1.31.0 and uses the 2018 edition.
# run tests
$ cargo test
# show syntax tree of a Rust file
$ cargo run --package ra_cli parse < crates/ra_syntax/src/lib.rs
# show symbols of a Rust file
$ cargo run --package ra_cli symbols < crates/ra_syntax/src/lib.rs
To try out the language server, see these instructions. Please note that the server is not ready for general use yet. If you are looking for a Rust IDE that works, use IntelliJ Rust or RLS. That being said, the basic stuff works, and rust analyzer is developed in the rust analyzer powered editor.
Current Status and Plans
Rust analyzer aims to fill the same niche as the official Rust Language Server, but uses a significantly different architecture. More details can be found in this thread, but the core issue is that RLS works in the "wait until user stops typing, run the build process, save the results of the analysis" mode, which arguably is the wrong foundation for IDE.
Rust Analyzer is a hobby project at the moment, there's exactly zero guarantees that it becomes production-ready one day.
The near/mid term plan is to work independently of the main rustc compiler and implement at least simplistic versions of name resolution, macro expansion and type inference. The purpose is two fold:
-
to quickly bootstrap usable and useful language server: solution that covers 80% of Rust code will be useful for IDEs, and will be vastly simpler than 100% solution.
-
to understand how the consumer-side of compiler API should look like (especially it's on-demand aspects). If you have
get_expression_typefunction, you can write a ton of purely-IDE features on top of it, even if the function is only partially correct. Plugin in the precise function afterwards should just make IDE features more reliable.
The long term plan is to merge with the mainline rustc compiler, probably around the HIR boundary? That is, use rust analyzer for parsing, macro expansion and related bits of name resolution, but leave the rest (including type inference and trait selection) to the existing rustc.
Getting in touch
We have a Discord server dedicated to compilers and language servers implemented in Rust: https://discord.gg/sx3RQZB.
Contributing
See CONTRIBUTING.md and ARCHITECTURE.md
License
Rust analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.