mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-25 00:03:43 +00:00
Merge #8255
8255: internal: touch up dev readme r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
This commit is contained in:
bors[bot]
GitHub
commit
563464bfae
@ -1,7 +1,7 @@
|
||||
# Contributing Quick Start
|
||||
|
||||
Rust Analyzer is an ordinary Rust project, which is organized as a Cargo
|
||||
workspace, builds on stable and doesn't depend on C libraries. So, just
|
||||
Rust Analyzer is an ordinary Rust project, which is organized as a Cargo workspace, builds on stable and doesn't depend on C libraries.
|
||||
So, just
|
||||
|
||||
```
|
||||
$ cargo test
|
||||
@ -13,9 +13,8 @@ To learn more about how rust-analyzer works, see [./architecture.md](./architect
|
||||
It also explains the high-level layout of the source code.
|
||||
Do skim through that document.
|
||||
|
||||
We also publish rustdoc docs to pages:
|
||||
|
||||
https://rust-analyzer.github.io/rust-analyzer/ide/
|
||||
We also publish rustdoc docs to pages: https://rust-analyzer.github.io/rust-analyzer/ide/.
|
||||
Note though, that internal documentation is very incomplete.
|
||||
|
||||
Various organizational and process issues are discussed in this document.
|
||||
|
||||
@ -49,21 +48,28 @@ https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0
|
||||
Also a kind of fun.
|
||||
These issues should generally include a link to a Zulip discussion thread.
|
||||
|
||||
# CI
|
||||
# Code Style & Review Process
|
||||
|
||||
We use GitHub Actions for CI. Most of the things, including formatting, are checked by
|
||||
`cargo test` so, if `cargo test` passes locally, that's a good sign that CI will
|
||||
be green as well. The only exception is that some long-running tests are skipped locally by default.
|
||||
Do see [./style.md](./style.md).
|
||||
|
||||
# Cookbook
|
||||
|
||||
## CI
|
||||
|
||||
We use GitHub Actions for CI.
|
||||
Most of the things, including formatting, are checked by `cargo test`.
|
||||
If `cargo test` passes locally, that's a good sign that CI will be green as well.
|
||||
The only exception is that some long-running tests are skipped locally by default.
|
||||
Use `env RUN_SLOW_TESTS=1 cargo test` to run the full suite.
|
||||
|
||||
We use bors-ng to enforce the [not rocket science](https://graydon2.dreamwidth.org/1597.html) rule.
|
||||
|
||||
# Launching rust-analyzer
|
||||
## Launching rust-analyzer
|
||||
|
||||
Debugging the language server can be tricky.
|
||||
LSP is rather chatty, so driving it from the command line is not really feasible, driving it via VS Code requires interacting with two processes.
|
||||
|
||||
For this reason, the best way to see how rust-analyzer works is to find a relevant test and execute it.
|
||||
For this reason, the best way to see how rust-analyzer works is to **find a relevant test and execute it**.
|
||||
VS Code & Emacs include an action for running a single test.
|
||||
|
||||
Launching a VS Code instance with a locally built language server is also possible.
|
||||
@ -107,12 +113,7 @@ cd editors/code
|
||||
npm ci
|
||||
npm run lint
|
||||
```
|
||||
|
||||
# Code Style & Review Process
|
||||
|
||||
Do see [./style.md](./style.md).
|
||||
|
||||
# How to ...
|
||||
## How to ...
|
||||
|
||||
* ... add an assist? [#7535](https://github.com/rust-analyzer/rust-analyzer/pull/7535)
|
||||
* ... add a new protocol extension? [#4569](https://github.com/rust-analyzer/rust-analyzer/pull/4569)
|
||||
@ -120,18 +121,17 @@ Do see [./style.md](./style.md).
|
||||
* ... add a new completion? [#6964](https://github.com/rust-analyzer/rust-analyzer/pull/6964)
|
||||
* ... allow new syntax in the parser? [#7338](https://github.com/rust-analyzer/rust-analyzer/pull/7338)
|
||||
|
||||
# Logging
|
||||
## Logging
|
||||
|
||||
Logging is done by both rust-analyzer and VS Code, so it might be tricky to
|
||||
figure out where logs go.
|
||||
Logging is done by both rust-analyzer and VS Code, so it might be tricky to figure out where logs go.
|
||||
|
||||
Inside rust-analyzer, we use the standard `log` crate for logging, and
|
||||
`env_logger` for logging frontend. By default, log goes to stderr, but the
|
||||
stderr itself is processed by VS Code.
|
||||
Inside rust-analyzer, we use the standard `log` crate for logging, and `env_logger` for logging frontend.
|
||||
By default, log goes to stderr, but the stderr itself is processed by VS Code.
|
||||
`--log-file <PATH>` CLI argument allows logging to file.
|
||||
|
||||
To see stderr in the running VS Code instance, go to the "Output" tab of the
|
||||
panel and select `rust-analyzer`. This shows `eprintln!` as well. Note that
|
||||
`stdout` is used for the actual protocol, so `println!` will break things.
|
||||
To see stderr in the running VS Code instance, go to the "Output" tab of the panel and select `rust-analyzer`.
|
||||
This shows `eprintln!` as well.
|
||||
Note that `stdout` is used for the actual protocol, so `println!` will break things.
|
||||
|
||||
To log all communication between the server and the client, there are two choices:
|
||||
|
||||
@ -139,17 +139,12 @@ To log all communication between the server and the client, there are two choice
|
||||
```
|
||||
env RA_LOG=lsp_server=debug code .
|
||||
```
|
||||
|
||||
By default, logs go to stderr, `--log-file <PATH>` CLI argument overrides
|
||||
that.
|
||||
|
||||
* You can log on the client side, by enabling `"rust-analyzer.trace.server":
|
||||
"verbose"` workspace setting. These logs are shown in a separate tab in the
|
||||
output and could be used with LSP inspector. Kudos to
|
||||
[@DJMcNab](https://github.com/DJMcNab) for setting this awesome infra up!
|
||||
* You can log on the client side, by enabling `"rust-analyzer.trace.server": "verbose"` workspace setting.
|
||||
These logs are shown in a separate tab in the output and could be used with LSP inspector.
|
||||
Kudos to [@DJMcNab](https://github.com/DJMcNab) for setting this awesome infra up!
|
||||
|
||||
|
||||
There are also two VS Code commands which might be of interest:
|
||||
There are also several VS Code commands which might be of interest:
|
||||
|
||||
* `Rust Analyzer: Status` shows some memory-usage statistics.
|
||||
|
||||
@ -167,7 +162,7 @@ There are also two VS Code commands which might be of interest:
|
||||
|
||||
|
||||
|
||||
# Profiling
|
||||
## Profiling
|
||||
|
||||
We have a built-in hierarchical profiler, you can enable it by using `RA_PROFILE` env-var:
|
||||
|
||||
@ -195,7 +190,9 @@ $ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --highlight .
|
||||
$ cargo run --release -p rust-analyzer -- analysis-bench ../chalk/ --complete ../chalk/chalk-engine/src/logic.rs:94:0
|
||||
```
|
||||
|
||||
# Release Process
|
||||
Look for `fn benchmark_xxx` tests for a quick way to reproduce performance problems.
|
||||
|
||||
## Release Process
|
||||
|
||||
Release process is handled by `release`, `dist` and `promote` xtasks, `release` being the main one.
|
||||
|
||||
@ -232,7 +229,7 @@ Make sure to remove the new changelog post created when running `cargo xtask rel
|
||||
We release "nightly" every night automatically and promote the latest nightly to "stable" manually, every week.
|
||||
We don't do "patch" releases, unless something truly egregious comes up.
|
||||
|
||||
# Permissions
|
||||
## Permissions
|
||||
|
||||
There are three sets of people with extra permissions:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user