f7f9757b6b
2396: Switch to variant-granularity field type inference r=flodiebold a=matklad
r? @flodiebold
Previously, we had a `ty` query for each field. This PR switcthes to a query per struct, which returns an `ArenaMap` with `Ty`s.
I don't know which approach is better. What is bugging me about the original approach is that, if we do all queries on the "leaf" defs, in practice we get a ton of queries which repeatedly reach into the parent definition to compute module, resolver, etc. This *seems* wasteful (but I don't think this is really what causes any perf problems for us).
At the same time, I've been looking at Kotlin, and they seem to use the general pattern of analyzing the *parent* definition, and storing info about children into a `BindingContext`.
I don't really which way is preferable. I think I want to try this approach, where query granularity generally mirrors the data granularity. The primary motivation for me here is probably just hope that we can avoid adding a ton of helpers to a `StructField`, and maybe in general avoid the need to switch to a global `StructField`, using `LocalStructFieldId` most of the time internally.
For external API (ie, for `ra_ide_api`), I think we should continue with fine-grained `StructField::ty` approach, which internally fetches the table for the whole struct and indexes into it.
In terms of actual memory savings, the results are as follows:
```
This PR:
142kb FieldTypesQuery (deps)
38kb FieldTypesQuery
Status Quo:
208kb TypeForFieldQuery (deps)
18kb TypeForFieldQuery
```
Note how the table itself occupies more than twice as much space! I don't have an explanation for this: a plausible hypothesis is that single-field structs are very common and for them the table is a pessimisation.
THere's noticiable wallclock time difference.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
|
||
|---|---|---|
| .cargo | ||
| .github | ||
| .vscode | ||
| crates | ||
| docs | ||
| editors | ||
| xtask | ||
| .gitattributes | ||
| .gitignore | ||
| bors.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| rustfmt.toml | ||
Rust Analyzer
Rust Analyzer is an experimental modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust. If you want to get involved, check the rls-2.0 working group in the compiler-team repository:
https://github.com/rust-lang/compiler-team/tree/master/content/working-groups/rls-2.0
Work on the Rust Analyzer is sponsored by
Language Server Quick Start
Rust Analyzer is a work-in-progress, so you'll have to build it from source, and you might encounter critical bugs. That said, it is complete enough to provide a useful IDE experience and some people use it as a daily driver.
To build rust-analyzer, you need:
- latest stable rust for language server itself
- latest stable npm and VS Code for VS Code extension
To quickly install rust-analyzer with VS Code extension with standard setup
(code and cargo in $PATH, etc), use this:
# clone the repo
$ git clone https://github.com/rust-analyzer/rust-analyzer && cd rust-analyzer
# install both the language server and VS Code extension
$ cargo xtask install
# alternatively, install only the server. Binary name is `ra_lsp_server`.
$ cargo xtask install --server
For non-standard setup of VS Code and other editors, see ./docs/user.
Documentation
If you want to contribute to rust-analyzer or just curious about how things work under the hood, check the ./docs/dev folder.
If you want to use rust-analyzer's language server with your editor of choice, check ./docs/user folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.
Getting in touch
We are on the rust-lang Zulip!
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frls-2.2E0
Quick Links
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.