Cache trait solving across queries in the same revision

Caching trait solving can do a lot to speed. Unfortunately it also consume a huge amount of memory. Therefore, as part of the migration to the new solver Jack Huey disabled caching of trait solving (he made the query transparent).

The PR proposes a middle ground: do cache trait solving, but only for the same revision. This allows us to be safe because during a revision the inputs cannot change.

The result is hopefully much better performance to features that tend to do a bulk of trait solving, and also repeat the same query (e.g. inference then IDE features).

There is another limitation: results are only cached in the same thread, to remove the need for synchronization which will be expensive. More measurements are required to check whether it's better to use a synchronized global cache, or maybe stay with a thread-local cache but batch multiple feature requests (highlighting, inlay hints etc.) of the same file to the same thread.

Alongside the actual cache we store the revision, because we need to verify it (we can't eagerly clear caches when incrementing the revision), and also the address of the db to prevent multiple dbs from interleaving (this is mostly relevant in tests, although injected highlighting also uses a new db, therefore maybe it's better to move it to a separate thread).

This "games" analysis-stats to both be way faster and use way more memory; the former is because analysis-stats doesn't increment revisions, therefore all queries share the cache and hit ratio is way too good, the latter is because analysis-stats doesn't increment revisions and therefore the cache isn't cleared. Both are not representative of a typical IDE scenario.
7 files changed
tree: 6d7dbc3ec87a1a66bbc14187a46c29e0e4b66f89
  1. .cargo/
  2. .github/
  3. .vscode/
  4. assets/
  5. bench_data/
  6. crates/
  7. docs/
  8. editors/
  9. lib/
  10. xtask/
  11. .editorconfig
  12. .git-blame-ignore-revs
  13. .gitattributes
  14. .gitignore
  15. .typos.toml
  16. Cargo.lock
  17. Cargo.toml
  18. clippy.toml
  19. CONTRIBUTING.md
  20. josh-sync.toml
  21. LICENSE-APACHE
  22. LICENSE-MIT
  23. PRIVACY.md
  24. README.md
  25. rust-version
  26. rustfmt.toml
  27. triagebot.toml
README.md

rust-analyzer is a 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.

Quick Start

https://rust-analyzer.github.io/book/installation.html

Documentation

If you want to contribute to rust-analyzer check out the CONTRIBUTING.md or if you are just curious about how things work under the hood, see the Contributing section of the manual.

If you want to use rust-analyzer's language server with your editor of choice, check the manual. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Security and Privacy

See the security and privacy sections of the manual.

Communication

For usage and troubleshooting requests, please use “IDEs and Editors” category of the Rust forum:

https://users.rust-lang.org/c/ide/14

For questions about development and implementation, join rust-analyzer working group on Zulip:

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer

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.