Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustc-dev-guide sync #138655

Merged
merged 11 commits into from
Mar 19, 2025
2 changes: 1 addition & 1 deletion src/doc/rustc-dev-guide/rust-version
Original file line number Diff line number Diff line change
@@ -1 +1 @@
8536f201ffdb2c24925d7f9e87996d7dca93428b
493c38ba371929579fe136df26eccd9516347c7a
26 changes: 25 additions & 1 deletion src/doc/rustc-dev-guide/src/building/suggested.md
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,30 @@ Another way is without a plugin, and creating your own logic in your
configuration. The following code will work for any checkout of rust-lang/rust (newer than Febuary 2025):

```lua
local function expand_config_variables(option)
local var_placeholders = {
['${workspaceFolder}'] = function(_)
return vim.lsp.buf.list_workspace_folders()[1]
end,
}

if type(option) == "table" then
local mt = getmetatable(option)
local result = {}
for k, v in pairs(option) do
result[expand_config_variables(k)] = expand_config_variables(v)
end
return setmetatable(result, mt)
end
if type(option) ~= "string" then
return option
end
local ret = option
for key, fn in pairs(var_placeholders) do
ret = ret:gsub(key, fn)
end
return ret
end
lspconfig.rust_analyzer.setup {
root_dir = function()
local default = lspconfig.rust_analyzer.config_def.default_config.root_dir()
Expand All @@ -142,7 +166,7 @@ lspconfig.rust_analyzer.setup {
-- load rust-lang/rust settings
local file = io.open(config)
local json = vim.json.decode(file:read("*a"))
client.config.settings["rust-analyzer"] = json.lsp["rust-analyzer"].initialization_options
client.config.settings["rust-analyzer"] = expand_config_variables(json.lsp["rust-analyzer"].initialization_options)
client.notify("workspace/didChangeConfiguration", { settings = client.config.settings })
end
return true
Expand Down
2 changes: 1 addition & 1 deletion src/doc/rustc-dev-guide/src/contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,7 @@ smaller user-facing changes.
into a PR that ends up not getting merged!** [See this document][mcpinfo] for
more info on MCPs.

[mcpinfo]: https://forge.rust-lang.org/compiler/mcp.html
[mcpinfo]: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#how-do-i-submit-an-mcp
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler

### Performance
Expand Down
2 changes: 1 addition & 1 deletion src/doc/rustc-dev-guide/src/implementing_new_features.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ like this; for example, the compiler team recommends
filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
garner support and feedback without requiring full consensus.

[mcp]: https://forge.rust-lang.org/compiler/mcp.html#public-facing-changes-require-rfcbot-fcp
[mcp]: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#how-do-i-submit-an-mcp

You don't need to have the implementation fully ready for r+ to propose an FCP,
but it is generally a good idea to have at least a proof
Expand Down
56 changes: 28 additions & 28 deletions src/doc/rustc-dev-guide/src/tests/running.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ a subset of test collections, and merge queue CI will exercise all of the test
collection.
</div>

```bash
```text
./x test
```

Expand All @@ -45,22 +45,22 @@ tests. For example, a good "smoke test" that can be used after modifying rustc
to see if things are generally working correctly would be to exercise the `ui`
test suite ([`tests/ui`]):

```bash
```text
./x test tests/ui
```

Of course, the choice of test suites is
somewhat arbitrary, and may not suit the task you are doing. For example, if you
are hacking on debuginfo, you may be better off with the debuginfo test suite:

```bash
```text
./x test tests/debuginfo
```

If you only need to test a specific subdirectory of tests for any given test
suite, you can pass that directory as a filter to `./x test`:

```bash
```text
./x test tests/ui/const-generics
```

Expand All @@ -73,27 +73,27 @@ suite, you can pass that directory as a filter to `./x test`:

Likewise, you can test a single file by passing its path:

```bash
```text
./x test tests/ui/const-generics/const-test.rs
```

`x` doesn't support running a single tool test by passing its path yet. You'll
have to use the `--test-args` argument as described
[below](#running-an-individual-test).

```bash
```text
./x test src/tools/miri --test-args tests/fail/uninit/padding-enum.rs
```

### Run only the tidy script

```bash
```text
./x test tidy
```

### Run tests on the standard library

```bash
```text
./x test --stage 0 library/std
```

Expand All @@ -102,13 +102,13 @@ crates, you have to specify those explicitly.

### Run the tidy script and tests on the standard library

```bash
```text
./x test --stage 0 tidy library/std
```

### Run tests on the standard library using a stage 1 compiler

```bash
```text
./x test --stage 1 library/std
```

Expand All @@ -122,7 +122,7 @@ the tests **usually** work fine with stage 1, there are some limitations.

### Run all tests using a stage 2 compiler

```bash
```text
./x test --stage 2
```

Expand All @@ -134,13 +134,13 @@ You almost never need to do this; CI will run these tests for you.

You may want to run unit tests on a specific file with following:

```bash
```text
./x test compiler/rustc_data_structures/src/thin_vec/tests.rs
```

But unfortunately, it's impossible. You should invoke the following instead:

```bash
```text
./x test compiler/rustc_data_structures/ --test-args thin_vec
```

Expand All @@ -151,7 +151,7 @@ often the test they are trying to fix. As mentioned earlier, you may pass the
full file path to achieve this, or alternatively one may invoke `x` with the
`--test-args` option:

```bash
```text
./x test tests/ui --test-args issue-1234
```

Expand Down Expand Up @@ -203,7 +203,7 @@ When `--pass $mode` is passed, these tests will be forced to run under the given
`$mode` unless the directive `//@ ignore-pass` exists in the test file. For
example, you can run all the tests in `tests/ui` as `check-pass`:

```bash
```text
./x test tests/ui --pass check
```

Expand All @@ -219,7 +219,7 @@ first look for expected output in `foo.polonius.stderr`, falling back to the
usual `foo.stderr` if not found. The following will run the UI test suite in
Polonius mode:

```bash
```text
./x test tests/ui --compare-mode=polonius
```

Expand All @@ -232,7 +232,7 @@ just `.rs` files, so after [creating a rustup
toolchain](../building/how-to-build-and-run.md#creating-a-rustup-toolchain), you
can do something like:

```bash
```text
rustc +stage1 tests/ui/issue-1234.rs
```

Expand All @@ -252,7 +252,7 @@ execution* so be careful where it is used.
To do this, first build `remote-test-server` for the remote machine, e.g. for
RISC-V

```sh
```text
./x build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu
```

Expand All @@ -264,7 +264,7 @@ On the remote machine, run the `remote-test-server` with the `--bind
0.0.0.0:12345` flag (and optionally `-v` for verbose output). Output should look
like this:

```sh
```text
$ ./remote-test-server -v --bind 0.0.0.0:12345
starting test server
listening on 0.0.0.0:12345!
Expand All @@ -278,7 +278,7 @@ restrictive IP address when binding.
You can test if the `remote-test-server` is working by connecting to it and
sending `ping\n`. It should reply `pong`:

```sh
```text
$ nc $REMOTE_IP 12345
ping
pong
Expand All @@ -288,15 +288,15 @@ To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment
variable then use `x` as usual. For example, to run `ui` tests for a RISC-V
machine with the IP address `1.2.3.4` use

```sh
```text
export TEST_DEVICE_ADDR="1.2.3.4:12345"
./x test tests/ui --target riscv64gc-unknown-linux-gnu
```

If `remote-test-server` was run with the verbose flag, output on the test
machine may look something like

```
```text
[...]
run "/tmp/work/test1007/a"
run "/tmp/work/test1008/a"
Expand Down Expand Up @@ -362,21 +362,21 @@ codegen-backends = ["llvm", "gcc"]

Then you need to install libgccjit 12. For example with `apt`:

```bash
$ apt install libgccjit-12-dev
```text
apt install libgccjit-12-dev
```

Now you can run the following command:

```bash
$ ./x test compiler/rustc_codegen_gcc/
```text
./x test compiler/rustc_codegen_gcc/
```

If it cannot find the `.so` library (if you installed it with `apt` for example), you
need to pass the library file path with `LIBRARY_PATH`:

```bash
$ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/ ./x test compiler/rustc_codegen_gcc/
```text
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/ ./x test compiler/rustc_codegen_gcc/
```

If you encounter bugs or problems, don't hesitate to open issues on the
Expand Down
Loading