aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_lsp_server/src/main_loop
Commit message (Collapse)AuthorAgeFilesLines
* Swallow expected `rustfmt` errorsRyan Cumming2019-06-261-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My workflow in Visual Studio Code + Rust Analyzer has become: 1. Make a change to Rust source code using all the analysis magic 2. Save the file to trigger `cargo watch`. I have format on save enabled for all file types so this also runs `rustfmt` 3. Fix any diagnostics that `cargo watch` finds Unfortunately if the Rust source has any syntax errors the act of saving will pop up a scary "command has failed" message and will switch to the "Output" tab to show the `rustfmt` error and exit code. I did a quick survey of what other Language Servers do in this case. Both the JSON and TypeScript servers will swallow the error and return success. This is consistent with how I remember my workflow in those languages. The syntax error will show up as a diagnostic so it should be clear why the file isn't formatting. I checked the `rustfmt` source code and while it does distinguish "parse errors" from "operational errors" internally they both result in exit status of 1. However, more catastrophic errors (missing `rustfmt`, SIGSEGV, etc) will return 127+ error codes which we can distinguish from a normal failure. This changes our handler to log an info message and feign success if `rustfmt` exits with status 1. Another option I considered was only swallowing the error if the formatting request came from format-on-save. However, the Language Server Protocol doesn't seem to distinguish those cases.
* renameAleksey Kladov2019-06-011-33/+33
|
* move completed requests to a separate fileAleksey Kladov2019-05-313-11/+81
|
* less noisy statusAleksey Kladov2019-05-291-1/+1
|
* add latest requests to status pageAleksey Kladov2019-05-291-2/+10
|
* rename stray id fieldPascal Hertleif2019-05-271-1/+1
|
* make it build againPascal Hertleif2019-05-271-1/+1
|
* Semantic highlighting spikePascal Hertleif2019-05-271-1/+5
| | | | | | | | | | Very simple approach: For each identifier, set the hash of the range where it's defined as its 'id' and use it in the VSCode extension to generate unique colors. Thus, the generated colors are per-file. They are also quite fragile, and I'm not entirely sure why. Looks like we need to make sure the same ranges aren't overwritten by a later request?
* add profile calls to real-time requestsAleksey Kladov2019-05-271-0/+5
|
* Basic resolution for ADTkjeremy2019-04-231-0/+20
|
* switch to official extend selection APIAleksey Kladov2019-04-211-1/+46
|
* add a couple of profiling pointsAleksey Kladov2019-04-141-0/+3
|
* Sends cwd info for runnables and code lensesRoberto Vidal2019-04-141-0/+5
|
* Refactor CallInfo function signatures to new FunctionSignature typeVille Penttinen2019-04-091-18/+5
| | | | | This is used by CallInfo to create a pretty printed function signature that can be used with completions and other places as well.
* Add optional range parameter to SyntaxTreeParamsVille Penttinen2019-03-031-1/+3
| | | | | When range is provided, instead of showing the syntax for the whole file, we'll show the syntax tree for the given range.
* Add new type HoverResult to contain the results of hoveringVille Penttinen2019-02-261-1/+1
| | | | | This makes testing hovers easier as well as allows us to do more things with the results if needed.
* Assign IDs to assistsAleksey Kladov2019-02-241-9/+39
|
* Update lsp-types and backtracekjeremy2019-02-211-1/+1
|
* Refactor find_all_refs to return ReferenceSearchResultVille Penttinen2019-02-171-10/+28
|
* Add support for container_name in workspace/symbol queryVille Penttinen2019-02-121-1/+1
|
* reformat the worldAleksey Kladov2019-02-082-62/+17
|
* Some clippy cleanupskjeremy2019-02-061-19/+15
|
* Fill deprecation for LSPkjeremy2019-02-051-1/+1
|
* Move commentkjeremy2019-02-041-12/+13
|
* Future proof by explicitly matching against Nonekjeremy2019-02-041-1/+1
|
* Add commentkjeremy2019-02-041-0/+4
|
* Implement lens for impls and support resolving lenses.Jeremy Kolb2019-02-041-2/+83
|
* formatJeremy Kolb2019-01-311-1/+3
|
* Use "▶" for test code lensJeremy Kolb2019-01-311-1/+1
| | | | I find that this makes code lenses stand out more.
* Merge #702bors[bot]2019-01-301-0/+20
|\ | | | | | | | | | | | | | | | | 702: Go to Implementation r=matklad a=kjeremy First half of #620 Co-authored-by: Jeremy Kolb <[email protected]> Co-authored-by: kjeremy <[email protected]>
| * Go to Implementation for structs and enumsJeremy Kolb2019-01-301-0/+20
| |
* | Pass Documentation up to LSP and add "rust" to our codeblocks thereJeremy Kolb2019-01-301-7/+4
|/
* align command namingAleksey Kladov2019-01-281-2/+2
|
* Don't use the reserved error codeDJMcNab2019-01-261-1/+1
|
* Return an lsp errorDJMcNab2019-01-261-5/+8
|
* Use the correct working directory for cargo metadata and rustfmtDJMcNab2019-01-261-4/+13
|
* Fold blocks of mod items.Andrea Pretto2019-01-251-0/+1
| | | | Fixes #572
* Fill in DocumentSymbol::detailHrvoje Ban2019-01-241-1/+1
|
* ad status commandAleksey Kladov2019-01-221-0/+4
|
* Merge #574bors[bot]2019-01-201-1/+5
|\ | | | | | | | | | | | | | | | | 574: refactor completions to use TextEdit instead of InsertText r=matklad a=gfreezy 1. migrate from `insertText` to `TextEdit` from `CompleteItem` 2. use `insta` to test completions Co-authored-by: gfreezy <[email protected]>
| * refactor completions to use TextEdit instead of InsertTextgfreezy2019-01-191-1/+5
| |
* | extend selection expands macros and can totally panicAleksey Kladov2019-01-201-4/+8
| |
* | somewhat better nameAleksey Kladov2019-01-201-1/+1
| |
* | make matching brace consistentAleksey Kladov2019-01-201-2/+1
|/
* more idiomatic codegfreezy2019-01-191-5/+6
|
* fix commentsgfreezy2019-01-191-31/+3
|
* rename modgfreezy2019-01-191-16/+31
|
* switch to lsp-typesAleksey Kladov2019-01-141-1/+1
|
* Add bench runnable and code lensJeremy Kolb2019-01-121-35/+39
|
* Merge #500bors[bot]2019-01-121-95/+46
|\ | | | | | | | | | | | | | | | | | | | | 500: Code lens support for running tests r=matklad a=kjeremy Supports running individual and mod tests. I feel like this kind of abuses the `Runnables` infrastructure but it works. Maybe later on down the line we should introduce a struct that is really just a tuple of binary, arguments, and environment and pass that back to the client instead. `run_single.ts` is just a paired down version of `runnables.ts` and there is duplication because I think run_single will probably change independent of runnables. Co-authored-by: Jeremy A. Kolb <[email protected]> Co-authored-by: Jeremy Kolb <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 15:49:23 +0000