aboutsummaryrefslogtreecommitdiff
path: root/editors/code/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * Add testsvsrs2020-07-033-10/+10
| |
| * Add runnable env support.vsrs2020-07-033-11/+40
| |
* | Pass CodeActionKind through our middleware to populate menusJeremy Kolb2020-07-021-2/+4
|/
* Merge #5188bors[bot]2020-07-023-1/+46
|\ | | | | | | | | | | | | | | 5188: Implement StatusBar r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Implement StatusBarAleksey Kladov2020-07-023-1/+46
| |
| |
| \
| \
| \
*---. \ Merge #5089 #5161 #5184 #5185 #5186bors[bot]2020-07-021-7/+19
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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](https://github.com/rust-analyzer/rust-analyzer/blob/9a4d02faf9c47f401b8756c3f7fcab2198f5f9cd/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 https://github.com/rust-analyzer/rust-analyzer/blob/a33eefa3b26000b3018e6bb873f18dbe15ab4ab7/crates/ra_ide/src/completion/complete_snippet.rs#L23-L24 Co-authored-by: BGluth <[email protected]> Co-authored-by: David Lattimore <[email protected]> Co-authored-by: Veetaha <[email protected]> Co-authored-by: Heyward Fann <[email protected]>
| | | * Force showing extension activation error pop-up notificationVeetaha2020-07-021-3/+11
| | | |
| | * | Always install required nightly extension if current one is not nightlyVeetaha2020-07-021-4/+8
| | |/
* | / Add reload workspace commandAleksey Kladov2020-07-013-4/+4
|/ /
* | Merge #5101bors[bot]2020-06-302-1/+6
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5101: Add expect -- a light-weight alternative to insta r=matklad a=matklad This PR implements a small snapshot-testing library. Snapshot updating is done by setting an env var, or by using editor feature (which runs a test with env-var set). Here's workflow for updating a failing test: ![expect](https://user-images.githubusercontent.com/1711539/85926956-28afa080-b8a3-11ea-9260-c6d0d8914d0b.gif) Here's workflow for adding a new test: ![expect-fresh](https://user-images.githubusercontent.com/1711539/85926961-306f4500-b8a3-11ea-9369-f2373e327a3f.gif) Note that colorized diffs are not implemented in this PR, but should be easy to add (we already use them in test_utils). Main differences from insta (which is essential for rust-analyzer development, thanks @mitsuhiko!): * self-updating tests, no need for a separate tool * fewer features (only inline snapshots, no redactions) * fewer deps (no yaml, no persistence) * tighter integration with editor * first-class snapshot object, which can be used to write test functions (as opposed to testing macros) * trivial to tweak for rust-analyzer needs, by virtue of being a workspace member. I think eventually we should converge to a single snapshot testing library, but I am not sure that `expect` is exactly right, so I suggest rolling with both insta and expect for some time (if folks agree that expect might be better in the first place!). # Editor Integration Implementation The thing I am most excited about is the ability to update a specific snapshot from the editor. I want this to be available to other snapshot-testing libraries (cc @mitsuhiko, @aaronabramov), so I want to document how this works. The ideal UI here would be a code action (:bulb:). Unfortunately, it seems like it is impossible to implement without some kind of persistence (if you save test failures into some kind of a database, like insta does, than you can read the database from the editor plugin). Note that it is possible to highlight error by outputing error message in rustc's format. Unfortunately, one can't use the same trick to implement a quick fix. For this reason, expect makes use of another rust-analyzer feature -- ability to run a single test at the cursor position. This does need some expect-specific code in rust-analyzer unfortunately. Specifically, if rust-analyzer notices that the cursor is on `expect!` macro, it adds a special flag to runnable's JSON. However, given #5017 it is possible to approximate this well-enough without rust-analyzer integration. Specifically, an extension can register a special runner which checks (using regexes) if rust-anlyzer runnable covers text with specific macro invocation and do special magic in that case. closes #3835 Co-authored-by: Aleksey Kladov <[email protected]>
| * Add light-weight snapshot testing library with editor integrationAleksey Kladov2020-06-272-1/+6
| |
* | Merge #5119bors[bot]2020-06-291-3/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | 5119: Show notification while SSR is in progress r=matklad a=davidlattimore Ideally we would (a) show progress and (b) allow cancellation, but at least now there's some indication to the user that something is happening. Co-authored-by: David Lattimore <[email protected]>
| * | Show notification while SSR is in progressDavid Lattimore2020-06-291-3/+9
| |/ | | | | | | Ideally we would (a) show progress and (b) allow cancellation, but at least now there's some indication to the user that something is happening.
* / Fix SSR prompt following #4919David Lattimore2020-06-271-1/+1
|/
* Merge #5017bors[bot]2020-06-265-83/+96
|\ | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Fix ts lintsvsrs2020-06-241-2/+2
| |
| * Switch to ShellExecution instead of full Taskvsrs2020-06-242-41/+45
| |
| * Add custom cargo runnersvsrs2020-06-245-56/+65
| |
* | Merge branch 'Veetaha-feat/sync-branch'Aleksey Kladov2020-06-252-103/+0
|\ \
| * | Migrate flycheck to fully-lsp-compatible progress reports (introduce ↵veetaha2020-06-182-103/+0
| | | | | | | | | | | | ra_progress crate)
* | | Append 10 random hex chars to temp artifact filesVeetaha2020-06-241-1/+5
| | |
* | | Don't mess with messy temp dir and just download into extension dirVeetaha2020-06-241-57/+23
| |/ |/| | | | | | | | | | | | | Temp dirs are messy. Dealing with them requires handling quite a bunch of edge cases. As proposed by lnicola this seems better to just put the temp files in the extension dir and not care much about suddenly leaving garbage. Instead we get shorter and less platform-caveat-y code. We will also assume users don't try to issue a download in different vscode windows simultaneously
| |
| \
| \
| \
*---. \ Merge #4992 #4993 #4994 #4997 #4998bors[bot]2020-06-233-49/+65
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Co-authored-by: Günther Wagner <[email protected]>
| | | * | Decouple http file stream logic from temp dir logicVeetaha2020-06-222-44/+57
| |_|/ / |/| | |
| | * | Make bootstrap error message more informative and better-fittingVeetaha2020-06-221-4/+8
| | | |
| * | | Never disable error logging on the frontendVeetaha2020-06-221-1/+0
|/ / /
* / / Hotfix skipping the first chunks of the artifactsVeetaha2020-06-221-6/+7
|/ /
* | Download artifacts into tmp dirVeetaha2020-06-202-11/+60
| |
* | Update workaround commentVeetaha2020-06-191-3/+2
| |
* | Add `rust-analyzer.gotoLocation` commandvsrs2020-06-183-0/+18
| |
* | Fix rust-analyzer.debug.openDebugPane optionvsrs2020-06-182-2/+2
|/
* Fix Run lens.vsrs2020-06-061-1/+1
|
* Remove hover contents marking as trusted.vsrs2020-06-051-15/+2
| | | | | Hover contents might be extracted from raw doc comments and need some validation.
* Add hover actions LSP extension documentation.vsrs2020-06-051-1/+1
|
* Add hover actions as LSP extensionvsrs2020-06-053-4/+66
|
* Fix review commentsMikhail Rakhmanov2020-06-032-3/+0
|
* Merge remote-tracking branch 'upstream/master' into compute-lazy-assitsMikhail Rakhmanov2020-06-023-21/+29
|\ | | | | | | | | # Conflicts: # crates/rust-analyzer/src/to_proto.rs
| * Spec better runnablesAleksey Kladov2020-06-021-1/+1
| |
| * New runnables APIAleksey Kladov2020-06-023-20/+28
| |
* | Preliminary implementation of lazy CodeAssitsMikhail Rakhmanov2020-06-024-38/+65
|/
* Move run commands to commands.tsAleksey Kladov2020-06-023-133/+134
|
* Merge #4580bors[bot]2020-06-026-52/+100
|\ | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Change Runnable.bin -> Runnable.kindveetaha2020-05-316-52/+97
| | | | | | | | | | | | 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.
| * Fix invoking cargo without consulting CARGO or standard installation pathsveetaha2020-05-312-4/+7
| |
* | Always derive from `process.env` when spawning a child process/shell executionAlin Sinpalean2020-05-311-1/+1
|/ | | | | | | | | | 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.
* Add `inRustProject` when-clause for commands.vsrs2020-05-272-0/+11
|
* Partially fix displaying inlay hints in Github PR diff viewsveetaha2020-05-261-4/+5
|
* Document `parentModule` experimental LSP requestAleksey Kladov2020-05-252-4/+4
|
* Cleanup lsp extensions on the client sideAleksey Kladov2020-05-256-127/+88
|
* Less rust-analyzer specific onEnterAleksey Kladov2020-05-253-7/+9
|