Commit Graph

23 Commits

Author SHA1 Message Date
Tetsuharu Ohzeki
445b4fc27f editor/code: Sort the style to import types
see:
- https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/consistent-type-imports.md
- https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/no-import-type-side-effects.md
2023-07-11 06:12:00 +09:00
Tetsuharu Ohzeki
72a3883a71 editor/code: Enable noUncheckedIndexedAccess ts option
https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess
2023-07-06 16:17:02 +09:00
Alex Kladov
832a64e290 feat: don't add panics to error jump list by default
To re-enable this, use

    "rust-analyzer.runnables.problemMatcher": [
        "$rustc",
        "$rust-panic"
    ],

setting.

closes: #14977
2023-06-30 22:23:13 +01:00
Aleksey Kladov
7bc60f512e feat: define problem matcher for panics in VS Code
Now in VS Code "go to next error" (`F8`) will bring you to the source of
a panic.
2023-05-06 16:49:42 +01:00
Jonas Schievink
55fdcbe339
Revert "fix: in VSCode, correctly resolve relative paths to errors" 2022-10-14 09:28:44 +02:00
Aleksey Kladov
5bbfea03cc fix: in VSCode, correctly resolve relative paths to errors
VS Code problem matcher are restricted to be static "regexes". You can't
create a problem matcher dynamically, and you can't use custom code in
lieu of problem matcher.

This creates a problem for rust/cargo compiler errors. They use paths
relative to the root of the Cargo workspace, but VS Code doesn't
necessary know where that root is.

Luckily, there's a way out: our current problem matcher is defined like
this:

    "fileLocation": [ "autoDetect", "${workspaceRoot}" ],

That means that relative pahts would be resoleved relative to workspace
root. VS Code allows to specify a command inside `${}`. So we can plug
custom logic there to fetch Cargo's workspace root!

And that's exactly what this PR is doing!
2022-10-08 23:25:13 +01:00
Jonas Schievink
c99a5ae312 Add "cargo clippy" task preset 2022-05-20 15:25:37 +02:00
Andrei Listochkin
f247090558 prettier run 2022-05-17 18:15:06 +01:00
Oliver Cooper
d246a5f58b
Undefined scope comment 2021-09-09 08:50:24 +12:00
Oliver Cooper
001608914b Removed deprecated Task constructor 2021-09-08 10:46:31 +12:00
Oliver Cooper
0517247bbc Don't filter cargo tasks by scope
Fixes #9093
2021-08-31 20:35:22 +12:00
Alex.F
d13f6ba750 use async version 2021-08-16 00:19:45 +08:00
Aleksey Kladov
ee995dbfd4 fix: fix shell injection in task spawning
closes #9058
2021-05-31 20:11:36 +03:00
Kirill Bulatov
a05163db14 Create tasks for all workspaces 2021-05-26 01:11:52 +03:00
Igor Aleksanov
5b26629a4d Support 'runnables' options in the vs code extension 2020-10-02 12:35:22 +03:00
vsrs
2791f37a04 Fix ts lints 2020-06-24 12:30:41 +03:00
vsrs
647b126da5 Switch to ShellExecution instead of full Task 2020-06-24 10:53:49 +03:00
vsrs
a43a9103bc Add custom cargo runners 2020-06-24 10:53:49 +03:00
veetaha
d605ec9c32 Change Runnable.bin -> Runnable.kind
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
2020-05-31 05:21:45 +03:00
veetaha
030d78345f Fix invoking cargo without consulting CARGO or standard installation paths 2020-05-31 03:10:23 +03:00
Jonathan Dickinson
1d8c25b75c tasks.json Support
Move the task provider anonymous class into a real class, as this seems
to be how Microsoft do this in their documentation.

resolveTask is now implemented, which is used by VSCode to determine how
to execute tasks that the user has defined in tasks.json.
2020-04-22 17:05:04 -07:00
Tim
6e535915bd Use namespace import 2020-03-31 09:06:46 +01:00
Tim
768aa4259f Add basic task support
This adds basic support for running `cargo build`, `cargo run`, etc.
2020-03-30 21:23:21 +01:00