No description
Find a file
Aleksey Kladov b0c4b776b5 internal: add simple smoke test for project model
Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.

So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.

Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.

Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.

Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.

Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
2021-07-20 16:23:57 +03:00
.cargo xtask: replace "lint" command by a simply cargo alias 2021-03-14 13:36:45 +01:00
.github internal: easier to skim CI logs 2021-07-20 15:55:44 +03:00
.vscode Add "Win Attach to Server" debug configuration 2021-01-25 17:46:03 +03:00
assets Add SVG logos to assets directory 2020-08-28 21:41:45 +10:00
bench_data Add benchmark test for mbe 2021-02-25 05:47:13 +08:00
crates internal: add simple smoke test for project model 2021-07-20 16:23:57 +03:00
docs docs: publish Explaining Rust Analyzer series 2021-07-19 23:41:15 +03:00
editors/code Rename the old server before update 2021-07-13 09:10:25 +03:00
lib minor: publish la_arena 2021-07-20 14:33:08 +03:00
xtask minor: drop dummy authors field 2021-07-05 14:19:41 +03:00
.gitattributes Rename ra_syntax -> syntax 2020-08-12 18:30:53 +02:00
.gitignore add open Cargo.toml action 2020-11-12 17:48:07 -08:00
bors.toml Reduce bors timeout 2020-10-14 13:37:20 +02:00
Cargo.lock internal: add simple smoke test for project model 2021-07-20 16:23:57 +03:00
Cargo.toml Build test-macros in a build script 2021-06-09 17:16:52 +02:00
LICENSE-APACHE Licenses 2018-01-10 22:47:04 +03:00
LICENSE-MIT Licenses 2018-01-10 22:47:04 +03:00
PRIVACY.md Consolidate the privacy notes 2021-06-15 20:07:59 +03:00
README.md Consolidate the privacy notes 2021-06-15 20:07:59 +03:00
rustfmt.toml Remove forcing \n via rustfmt 2019-11-02 22:19:59 +03:00

rust-analyzer logo

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.

Work on rust-analyzer is sponsored by

Ferrous Systems

Quick Start

https://rust-analyzer.github.io/manual.html#installation

Documentation

If you want to contribute to rust-analyzer or are 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 the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Security and Privacy

See the corresponding 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

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.