| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4448: Generate configuration for launch.json r=vsrs a=vsrs
This PR adds two new commands: `"rust-analyzer.debug"` and `"rust-analyzer.newDebugConfig"`. The former is a supplement to the existing `"rust-analyzer.run"` command and works the same way: asks for a runnable and starts new debug session. The latter allows adding a new configuration to **launch.json** (or to update an existing one).
If the new option `"rust-analyzer.debug.useLaunchJson"` is set to true then `"rust-analyzer.debug"` and Debug Lens will first look for existing debug configuration in **launch.json**. That is, it has become possible to specify startup arguments, env variables, etc.
`"rust-analyzer.debug.useLaunchJson"` is false by default, but it might be worth making true the default value. Personally I prefer true, but I'm not sure if it is good for all value.
----
I think that this PR also solves https://github.com/rust-analyzer/rust-analyzer/issues/3441.
Both methods to update launch.json mentioned in the issue do not work:
1. Menu. It is only possible to add a launch.json configuration template via a debug adapter. And anyway it's only a template and it is impossible to specify arguments from an extension.
2. DebugConfigurationProvider. The exact opposite situation: it is possible to specify all debug session settings, but it is impossible to export these settings to launch.json.
Separate `"rust-analyzer.newDebugConfig"` command looks better for me.
----
Fixes #4450
Fixes #3441
Co-authored-by: vsrs <[email protected]>
Co-authored-by: vsrs <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Add the possibility to use existing configurations via Debug Lens
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4400: Enhanced coloring r=georgewfraser a=georgewfraser
This PR builds on #4397 to enhance the existing syntax coloring.
## Underline mutable variables
The textmate scope `markup.underline` underlines identifiers, which is a nice way to make mutable vars stand out:
<img width="327" alt="Screen Shot 2020-05-09 at 1 18 55 PM" src="https://user-images.githubusercontent.com/1369240/81484179-8bb47d80-91f8-11ea-997d-1dcffbe44aa7.png">
## Italicize static variables
The textmate scope `markup.italic` italicizes identifiers. Italic = static is a common convention in IDEs like IntelliJ:
<img width="288" alt="Screen Shot 2020-05-09 at 1 19 14 PM" src="https://user-images.githubusercontent.com/1369240/81484236-cd452880-91f8-11ea-8478-505ee49bc8b3.png">
Co-authored-by: George Fraser <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| | |
latest stable
|
| | |
|
| |
| |
| |
| | |
TextMate and semantic
|
| | |
|
|/
|
|
| |
grammar and other languages
|
|\
| |
| |
| |
| | |
# Conflicts:
# editors/code/src/commands/runnables.ts
|
| | |
|
| |
| |
| |
| | |
This works around https://github.com/microsoft/vscode/issues/97162
|
| |
| |
| |
| | |
https://github.com/microsoft/vscode/issues/94367#issuecomment-608629883
|
| | |
|
| |
| |
| | |
Co-authored-by: bjorn3 <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
4166: Defining a default target to support cross-compilation targets r=matklad a=FuriouZz
Related to #4163
Co-authored-by: Christophe MASSOLIN <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `workspaceLoaded` notification setting was originally designed to
control the display of a popup message that said:
"workspace loaded, {} rust packages"
This popup was removed and replaced by a much sleeker message in the
VSCode status bar that provides a real-time status while loading:
rust-analyzer: {}/{} packages
This was done as part of #3587
The new status-bar indicator is unobtrusive and shouldn't need to be
disabled. So this setting is removed.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4222: Introduce C/C++ for Visual Studio Code extension as an alternative debug engine for Debug Code lens. r=matklad a=vsrs
At the moment Debug Code Lens can use only one debug engine: lldb via [CodeLLDB](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) extension.
This PR adds support of the debug engine from the [MS C++ tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) extension, as well as the configuration option. If both extensions are installed, `CodeLLDB` will be used by default.
Another new option `rust-analyzer.debug.sourceFileMap` allows, for example, to step into Rust std library during debugging. Works only with `MS C++ tools`.
On Windows:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "${env:USERPROFILE}/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust"
}
```
On Linux:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust"
}
```
Co-authored-by: vsrs <[email protected]>
|
| | | |
|
| | | |
|
| |/ |
|
|/ |
|
|
|
|
|
| |
We are transitioning from experimental to production-ready stance, so
it makes sense to disable potentially disruptive features by default.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
4090: Fix config naming r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| | |
We use `enable`, not `enabled` elsewhere
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a quick way to implement unresolved reference diagnostics.
For example, adding to VS Code config
"editor.tokenColorCustomizationsExperimental": {
"unresolvedReference": "#FF0000"
},
will highlight all unresolved refs in red.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
3962: Fix parentModule shortcut conflict r=matklad a=CodeSandwich
The default parentModule shortcut conflicts with VSCode's built-in undo selection
Co-authored-by: Igor Żuk <[email protected]>
|
| |
| |
| | |
The default parentModule shortcut conflicts with VSCode's built-in undo selection
|
|/ |
|
|
|
|
|
|
|
| |
This is covered under vscode's "editor.semanticHighlighting.enabled"
setting plus the user has to have a theme that has opted into highlighting.
Bumps required vscode stable to 1.44
|
| |
|