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 <vit@conrlab.com>
3998: Make add_function generate functions in other modules via qualified path r=matklad a=TimoFreiberg
Additional feature for #3639
- [x] Add tests for paths with more segments
- [x] Make generating the function in another file work
- [x] Add `pub` or `pub(crate)` to the generated function if it's generated in a different module
- [x] Make the assist jump to the edited file
- [x] Enable file support in the `check_assist` helper
4006: Syntax highlighting for format strings r=matklad a=ltentrup
I have an implementation for syntax highlighting for format string modifiers `{}`.
The first commit refactors the changes in #3826 into a separate struct.
The second commit implements the highlighting: first we check in a macro call whether the macro is a format macro from `std`. In this case, we remember the format string node. If we encounter this node during syntax highlighting, we check for the format modifiers `{}` using regular expressions.
There are a few places which I am not quite sure:
- Is the way I extract the macro names correct?
- Is the `HighlightTag::Attribute` suitable for highlighting the `{}`?
Let me know what you think, any feedback is welcome!
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
Co-authored-by: Leander Tentrup <ltentrup@users.noreply.github.com>
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.
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.
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
In textmate, keyword.control is used for all kinds of things; in fact,
the default scope mapping for keyword is keyword.control!
So let's add a less ambiguous controlFlow modifier
See Microsoft/vscode#94367
3844: vscode: restore removed default values r=matklad a=Veetaha
After refactoring the config we forgot to set defaults for
some properties like workspaceLoaded, callInfo.full, etc.
This commit restored them to being turned on by defult,
as well added defaults for other props to be more explicit
on their defualt value.
cc @matklad
Co-authored-by: veetaha <veetaha2@gmail.com>
After refactoring the config we forgot to set defaults for
some properties like workspaceLoaded, callInfo.full, etc.
This commit restored them to being turned on by defult,
as well added defaults for other props to be more explicit
on their defualt value.
