Add dedicated field for `target_dir` in the configurations for Cargo
and Flycheck. Also change the directory to be a `PathBuf` as opposed to
a `String` to be more appropriate to the operating system.
Adds a Rust Analyzer configuration option to set a custom
target directory for builds. This is a workaround for Rust Analyzer
blocking debug builds while running `cargo check`. This change
should close#6007
internal: fix automatic rustc/rustdoc lint generation
Missed in #15680: the output of `-Whelp` changed since the last run so it generated some bad rustdoc lints entries.
Also preemptively fix a `-Whelp` breakage that might get merged in rust-lang/rust#116412
According to the VS Code documentation, the vscode.open command opens the URL
_in the editor_ (https://code.visualstudio.com/api/references/commands).
However, in reality, it seems to do so only for file:// URLs, falling back to
other applications for other URL schemes (at least for HTTP/HTTPS).
Until now, the URL to the documentation was always HTTP based, so using the
vscode.open command was perfectly fine. However, displaying local documentation
will be supported from now on (see next commit). Local documentation is not
HTTP-based, but instead addressed via a file:// URL. The file URL would
therefore be opened in VS Code instead of in the browser — this is definitely
not what the user wants.
Therefore, the vscode.env.openExternal function is used instead, this function
never opens the URL in VS Code.
fix: ensure `rustfmt` runs when configured with `./`
(Hopefully) resolves https://github.com/rust-lang/rust-analyzer/issues/15595. This change kinda approaches canonicalization—which I am not a fan of—but only in service of making `./`-configured commands run correctly.
Longer-term, I feel like this code should be removed once `rustfmt` supports recursive searches of configuration files or interpolation of values like `${workspace_folder}` lands in rust-analyzer.
## Testing
I cloned `rustc`, setup rust-analyzer as suggested in the [`rustc` dev guide](https://rustc-dev-guide.rust-lang.org/building/suggested.html#configuring-rust-analyzer-for-rustc), saved and formatted files in `src/tools/miri` and `compiler`, and saw `rustfmt` (seemingly) correctly.
feat: add backtick to surrounding and auto-closing pairs
Makes backticks always complete as a pair and also surround the current selection, similar to double quotes. This is useful primarily in the context of markdown doc comments, but is applied globally for simplicity.
Closes https://github.com/rust-lang/rust-analyzer/issues/11381
vscode: Fix line and col regexp for `rustc` problem matcher
When building the Rust compiler with `./x check` from within VS Code, the current `rustc` problem matcher thinks that the output from that command that looks like this:
Build completed successfully in 0:00:26
is about a problem in a file named `0` on line 00, col 26. This wouldn't be so bad if it wasn't for that VS Code tends to get stuck on this problem because of problems with opening the file '0'.
The rust compiler will never output problems with a line or a column that starts with 0, so change the regexp to require lines and cols to begin with `[1-9]` to fix this problem.
fix: allow more kinds of if let patterns in guarded return assist
Removes the checks that require the pattern to be a tuple struct with exactly 1 field that is unqualified and has an identifier pattern in it. I'm not sure if there should be more checks in place but they seem unnecessary now?
Closes#15695
When building the Rust compiler with `./x check` from within VS Code,
the current `rustc` problem matcher thinks that the output from that
command that looks like this:
Build completed successfully in 0:00:26
is about a problem in a file named `0` on line 00, col 26. This wouldn't
be so bad if it wasn't for that VS Code tends to get stuck on this
problem because of problems with opening the file '0'.
The rust compiler will never output problems with a line or a column
that starts with 0, so change the regexp to require lines and cols to
begin with [1-9] to fix this problem.
Only run tests on linux in pull requests
There is little gain from running them on all platforms, they should almost never fail if the linux one pass and if they do, bors will catch it still.
