4580: Fix invoking cargo without consulting CARGO env var or standard installation paths r=matklad a=Veetaha
Followup for #4329
The pr essentially fixes [this bug](https://youtu.be/EzQ7YIIo1rY?t=2189)
cc @lefticus
Co-authored-by: veetaha <veetaha2@gmail.com>
This is useful when an extension (e.g. Nix Environment Selector) or launch
configuration sets one or more environment variables.
When `env` is not explicitly specified in the options passed to
`child_process.spawn()` or `vscode.ShellExecution()`, then `process.env` gets
applied automatically. But when an explicit `env` is set, it should inherit from
`process.env` rather than replace it completely.
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.
4555: VSCode: added patchelf after download for NixOS support r=matklad a=cab404
This adds Nix support, and fixes#4542
4575: Use Chalk's built-in representations for fn items and pointers r=matklad a=flodiebold
The `TypeName::FnDef` was just added; the function pointer variant has existed for a while, I just forgot about it because it's special (because fn pointers can be higher-ranked over lifetimes).
We *could* also make `FnPtr` a separate `Ty` variant instead of a `TypeCtor` variant, which would make the conversion code a bit less special-casey, but it doesn't seem worth doing right now.
Co-authored-by: Vladimir Serov <me@cab404.ru>
Co-authored-by: Cabia Rangris <me@cab404.ru>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This also changes our handiling of snippet edits on the client side.
`editor.insertSnippet` unfortunately forces indentation, which we
really don't want to have to deal with. So, let's just implement our
manual hacky way of dealing with a simple subset of snippets we
actually use in rust-analyzer
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#4450Fixes#3441
Co-authored-by: vsrs <vit@conrlab.com>
Co-authored-by: vsrs <62505555+vsrs@users.noreply.github.com>
4083: Smol documentation for ast nodes r=matklad a=Veetaha
There is a tremendous amount of TODOs to clarify the topics I am not certain about.
Please @matklad, @edwin0cheng review carefully, I even left some mentions of your names in todos to put your attention where you most probably can give comments.
In order to simplify the review, I separated the codegen (i.e. changes in `ast/generated/nodes.rs`) from `ast_src` changes (they in fact just duplicate one another) into two commits.
Also, I had to hack a little bit to let the docs be generated as doc comments and not as doc attributes because it's easier to read them this way and IIRC we don't support hints for `#[doc = ""]` attributes for now...
Closes#3682
Co-authored-by: veetaha <veetaha2@gmail.com>
4329: Look for `cargo`, `rustc`, and `rustup` in standard installation path r=matklad a=cdisselkoen
Discussed in #3118. This is approximately a 90% fix for the issue described there.
This PR creates a new crate `ra_env` with a function `get_path_for_executable()`; see docs there. `get_path_for_executable()` improves and generalizes the function `cargo_binary()` which was previously duplicated in the `ra_project_model` and `ra_flycheck` crates. (Both of those crates now depend on the new `ra_env` crate.) The new function checks (e.g.) `$CARGO` and `$PATH`, but also falls back on `~/.cargo/bin` manually before erroring out. This should allow most users to not have to worry about setting the `$CARGO` or `$PATH` variables for VSCode, which can be difficult e.g. on macOS as discussed in #3118.
I've attempted to replace all calls to `cargo`, `rustc`, and `rustup` in rust-analyzer with appropriate invocations of `get_path_for_executable()`; I don't think I've missed any in Rust code, but there is at least one invocation in TypeScript code which I haven't fixed. (I'm not sure whether it's affected by the same problem or not.) a4778ddb7a/editors/code/src/cargo.ts (L79)
I'm sure this PR could be improved a bunch, so I'm happy to take feedback/suggestions on how to solve this problem better, or just bikeshedding variable/function/crate names etc.
cc @Veetaha
Fixes#3118.
Co-authored-by: Craig Disselkoen <craigdissel@gmail.com>
Co-authored-by: veetaha <veetaha2@gmail.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 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
