| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5017: Add custom cargo runners support. r=matklad a=vsrs
This PR adds an option to delegate actual cargo commands building to another extension. For example, to use a different manager like [cross](https://github.com/rust-embedded/cross).
https://github.com/vsrs/cross-rust-analyzer is an example of such extension. I'll publish it after the rust-analyzer release with this functionality.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4902
Co-authored-by: vsrs <[email protected]>
|
| | | |
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| | |
ra_progress crate)
|
| | | | |
| | \ | |
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4992: Never disable error logging on the frontend r=matklad a=Veetaha
4993: Make bootstrap error message more informative and better-fitting r=matklad a=Veetaha
Now this better fits standard vscode extension activation failure message and suggests enabling verbose logs.
4994: Decouple http file stream logic from temp dir logic r=matklad a=Veetaha
Followup for #4989
4997: Update manual.adoc r=matklad a=gwutz
GNOME Builder (Nightly) supports now rust-analyzer
4998: Disrecommend trace.server: "verbose" for regular users r=matklad a=Veetaha
This option has never been useful for me, I wonder if anyone finds regular users can use this for sending logs
Co-authored-by: Veetaha <[email protected]>
Co-authored-by: Günther Wagner <[email protected]>
|
| | |/ /
|/| | |
|
| |/ / |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Users now can assign a shortcut for this command
via the general vscode
keybindings ui or `keybinding.json file`
Closes: #4599
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
Co-authored-by: Cabia Rangris <[email protected]>
Co-authored-by: Florian Diebold <[email protected]>
|
| | |\ |
|
| | | |
| | |
| | | |
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This adds basic support for running `cargo build`, `cargo run`, etc.
|
| |
|
|
| |
Co-Authored-By: Veetaha <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
The memory leak was because on the server restrart the array of extensionContext.substiptions was not cleared
|
| |
|
|
| |
The value of releaseTag is not undefined, but null in actual package.json
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Everything now happens in main.ts, in the bootstrap family of
functions. The current flow is:
* check everything only on extension installation.
* if the user is on nightly channel, try to download the nightly
extension and reload.
* when we install nightly extension, we persist its release id, so
that we can check if the current release is different.
* if server binary was not downloaded by the current version of the
extension, redownload it (we persist the version of ext that
downloaded the server).
|
| |
|
|
|
| |
That way, we clearly see which things are not change, and we also
clearly see which things are persistent.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3534: Feature: vscode impl nightlies download and installation r=Veetaha a=Veetaha
I need to test things more, but the core shape of the code is quite well-formed.
The main problem is that we save the release date only for nightlies and there are no means to get the release date of the stable extension (i.e. for this we would need to consult the github releases via a network request, or we would need to somehow save this info into package.json or any other file accessible from the extension code during the deployment step, but this will be very hard I guess).
So there is an invariant that the users can install nightly only from our extension and they can't do it manually, because when installing the nightly `.vsix` we actually save its release date to `globalState`
Closes: #3402
TODO:
- [x] More manual tests and documentation
cc @matklad @lnicola
Co-authored-by: Veetaha <[email protected]>
Co-authored-by: Veetaha <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
Refs #3539
|
