7001: Add support for downloading aarch64-apple-darwin binaries r=matklad a=lnicola
There's also a slight behavior change here: we no longer download our 64-binaries on 32-bit Darwin and Linux. We still do that on Windows, as I don't know how to detect 32-bit Node on 64 Windows.
But some people install the 32-bit Code by mistake, I doubt 32-bit Windows is that popular in the Rust crowd.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
The motivation in #5641 isn't too strong, but /etc/os-release exists on
pretty much every Linux distro, while /etc/nixos sounds like an
implementation detail.
The previous version would have interpreted an empty token as
an abort of the dialog and would have not properly cleared the token.
This is now fixed by checking for `undefined` for a an abort and
by setting the token to `undefined` in order to clear it.
This change allows to use a authorization token provided by Github in
order to fetch metadata for a RA release. Using an authorization token
prevents to get rate-limited in environments where lots of RA users use
a shared client IP (e.g. behind a company NAT).
The auth token is stored in `ExtensionContext.globalState`.
As far as I could observe through testing with a local WSL2 environment
that state is synced between an extension installed locally and a remote
version.
The change provides no explicit command to query for an auth token.
However in case a download fails it will provide a retry option as well
as an option to enter the auth token. This should be more discoverable
for most users.
Closes#3688
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Override miniz_oxide to build it with optimizations
Building this crate with optimizations decreases the gzipping
part of `cargo xtask dist` from `30-40s` down to `3s`,
the overhead for `rustc` to apply optimizations is miserable on this background
5089: Disable auto-complete on comments r=matklad a=BGluth
Resolves#4907 by disabling any auto-completion on comments.
As flodiebold [pointed out](https://github.com/rust-analyzer/rust-analyzer/issues/4907#issuecomment-648439979), in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.
The implementation involves adding a new field `is_comment` to `CompletionContext` and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.
Finally, the three tests I added should I think ideally not filter results by `CompletionKind::Keyword`, but if I want to get unfiltered results, I need access to a non-public function [get_all_completion_items](9a4d02faf9/crates/ra_ide/src/completion/test_utils.rs (L32-L39)) which I don't know if I should make public just for this.
5161: SSR: Add initial support for placeholder constraints r=matklad a=davidlattimore
5184: Always install required nightly extension if current one is not nightly r=matklad a=Veetaha
This is weird, but having switched back to stable by uninstalling the extension appears that vscode doesn't destroy the `PersistentState` and thus changing to `nightly` channel doesn't work because the last check for nightly extension was less than 1 hour ago. The simple solution is to skip this check if we know that the current extension version is not nightly.
5185: Force showing extension activation error pop-up notification r=matklad a=Veetaha
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5091
5186: fix: correct pd/ppd/tfn/tmod completion doc r=matklad a=fannheyward
a33eefa3b2/crates/ra_ide/src/completion/complete_snippet.rs (L23-L24)
Co-authored-by: BGluth <gluthb@gmail.com>
Co-authored-by: David Lattimore <dml@google.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: Heyward Fann <fannheyward@gmail.com>
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.
![image](https://user-images.githubusercontent.com/36276403/85321828-ffbb9400-b4cd-11ea-8adf-4032b1f62dfd.png)
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 <veetaha2@gmail.com>
Co-authored-by: Günther Wagner <info@gunibert.de>
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
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).
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 <gerzoh1@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>