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.
extend check.overrideCommand and buildScripts.overrideCommand docs
Extend check.overrideCommand and buildScripts.overrideCommand docs regarding invocation strategy and location.
However something still seems a bit odd -- the docs for `invocationStrategy`/`invocationLocation` talk about "workspaces", but the setting that controls which workspaces are considered is called `linkedProjects`. Is a project the same as a workspace here or is there some subtle difference?
Increase the buffer size for discover project command
The default value for maxBuffer is 1 MiB[1]. If the discover project command returns stdout or stderr that is greater than 1 MiB, the extension would error with "RangeError: stderr maxBuffer length exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
The default value for maxBuffer is 1 MiB[1]. If the discover project
command returns stdout or stderr that is greater than 1 MiB, the
extension would error with "RangeError: stderr maxBuffer length
exceeded".
Set the default value for maxBuffer to 10 MiB for project discovery.
[1] https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback
Use the warning color when rust-analyzer is stopped
If the rust-analyzer server isn't running, we can't do much. Treat this state as a warning color, so it's more obvious.
Previously, clicking 'rust-analyzer' would stop the server
entirely. This was easy to do accidentally, and then the user has to
wait for the server to start up again.
editor/code: Break down CI steps to know what is failing easily
This do the thing I mentioned in https://github.com/rust-lang/rust-analyzer/pull/15265#issuecomment-1634424385
This aims to improve CI status check more readable.
I tried to use [`jobs.<job_id>.if`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif) to make the configuration
more shortly once.
But it could not fire the `end-success` or `end-failure` status if some jobs in the workflow were skipped. This causes an integration problem with bors.
By their reasons, this patch still uses `jobs.<job_id>.steps[*].if`.
---
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically because ESLint's autofix doees not follow prettier's formatting. So we need to run `npm run lint:fix && npm run format` by this order.
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically
because ESLint's autofix doees not follow prettier's formatting.
So we need to run `npm run lint:fix && npm run format` by this order.
