aboutsummaryrefslogtreecommitdiff
path: root/crates/ide/src
Commit message (Collapse)AuthorAgeFilesLines
* honor content_format clientcapRobin van Dijk2020-10-053-7/+64
| | | | | | This removes all markdown when the client does not support the markdown MarkupKind Otherwise the output on the editor will have some markdown boilerplate, making it less readable
* Improve readability in inlay_hints.rsIgor Aleksanov2020-10-031-4/+5
|
* Remove 'for_expr' test from inlay_hints.rsIgor Aleksanov2020-10-031-14/+1
|
* Make the tests for complete/incomplete for inlay hints workIgor Aleksanov2020-10-031-10/+77
|
* Better inlay hints in 'for' loopsIgor Aleksanov2020-10-031-2/+49
|
* rename mock_analysis -> fixtureAleksey Kladov2020-10-0223-99/+90
|
* Get rid of MockAnalysisAleksey Kladov2020-10-0218-414/+280
|
* Move ide::AnalysisChange -> base_db::ChangeAleksey Kladov2020-10-023-10/+7
| | | | | | This seems like a better factoring logically; ideally, clients shouldn't touch `set_` methods of the database directly. Additionally, I think this should remove the unfortunate duplication in fixture code.
* Expectify find_references testsAleksey Kladov2020-10-021-176/+181
|
* Reduce visibiityAleksey Kladov2020-10-022-13/+14
|
* Use expect_test to make format_str_parser test more data-drivenIgor Aleksanov2020-10-021-35/+35
|
* Use lookup table instead of enum for postfix completion kindsIgor Aleksanov2020-10-021-62/+20
|
* Use ast::String for extracting string literal contentsIgor Aleksanov2020-10-022-14/+19
|
* Improve format-like completions code appearanceIgor Aleksanov2020-10-022-32/+26
|
* Add missing entry to doc-commentIgor Aleksanov2020-10-021-0/+1
|
* Simplify is_string_literal functionIgor Aleksanov2020-10-021-9/+5
|
* Improve checks for postfix suggestionsIgor Aleksanov2020-10-023-16/+23
|
* Add postfix completion for format-like string literalsIgor Aleksanov2020-10-023-1/+376
|
* Minor clippy performance suggestionskjeremy2020-09-301-2/+2
|
* Extend **Status** command to also show dep info for the fileAleksey Kladov2020-09-292-18/+35
| | | | This should help with troubleshooting wrong project configuration
* Remove periodic gc stubAleksey Kladov2020-09-292-7/+2
|
* Add testsvsrs2020-09-291-3/+77
|
* Do not show references CodeLens for tests.vsrs2020-09-293-14/+26
|
* Make method references CodeLens lazy.vsrs2020-09-291-1/+16
|
* Add hover config `linksInHover` to suppress linksflw2020-09-293-12/+146
|
* Merge #6055bors[bot]2020-09-251-0/+5
|\ | | | | | | | | | | | | | | | | | | 6055: Add ok postfix completion r=matklad a=mullr Wrapping values in `Ok(...)` is so pervasive that it seems reasonable for it to have its own postfix completion. Co-authored-by: Russell Mull <[email protected]>
| * Cargo fmtRussell Mull2020-09-221-9/+2
| |
| * Add ok postfix completionRussell Mull2020-09-221-0/+12
| |
* | Merge #6072bors[bot]2020-09-252-6/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 6072: Cleanup unintended unresolved reference in syntax higlighting test r=matklad a=Nashenas88 Fixes the issue brought up here https://github.com/rust-analyzer/rust-analyzer/pull/5957#discussion_r486625707 cc @jonas-schievink Co-authored-by: Paul Daniel Faria <[email protected]>
| * | Cleanup unintended unresolved reference in syntax higlighting testPaul Daniel Faria2020-09-242-6/+6
| | |
* | | Merge #6056bors[bot]2020-09-241-0/+12
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 6056: Add dbgr postfix completion r=matklad a=lnicola Expanding to `dbg!(&e)`. Co-authored-by: Laurențiu Nicola <[email protected]>
| * | Add dbgr postfix completionLaurențiu Nicola2020-09-221-0/+12
| | |
* | | Merge #5846bors[bot]2020-09-242-3/+130
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5846: Add references to fn args during completion r=matklad a=adamrk When completing a function call, if there is an argument taken as a ref or mut ref which matches the name and type of a variable in scope, we will insert a `&` or `&mut` when filling in the function arguments. This addresses https://github.com/rust-analyzer/rust-analyzer/issues/5449. E.g. ```rust fn foo(x: &i32) {} fn main() { let x = 5; foo # completing foo here generates `foo(&x)` now instead of `foo(x)` } ``` Co-authored-by: adamrk <[email protected]>
| * | Trim mut keyword in fn completionadamrk2020-09-021-1/+22
| | |
| * | Remove exposing unificationadamrk2020-09-021-1/+1
| | |
| * | Collect locals in contextadamrk2020-09-022-12/+15
| | |
| * | Add back Param structadamrk2020-09-011-1/+1
| | |
| * | Add references to fn args during completionadamrk2020-08-301-2/+105
| | |
* | | Update testsJonas Schievink2020-09-161-5/+57
| |/ |/|
* | Avoid checking all ancestors and fix mis-completionoxalica2020-09-151-33/+215
| |
* | inline parameters for a function description #6002Benjamin Coenen2020-09-151-5/+6
| | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | inline parameters for a function description #6002Benjamin Coenen2020-09-152-1/+29
| | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | Merge #5976bors[bot]2020-09-141-56/+119
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5976: Complete trait impl immediately after type/const/fn r=jonas-schievink a=oxalica Currently, we can complete type/const/fn but only if we typed an identifier. That is, `impl .. { fn f<|> }` has completions with all trait fn including `f`, but `impl .. { fn <|> }` doesn't provide any suggestion (even if explicit trigger it). This PR tweak the logic of completion match to make it possible. However, we still need to explicit trigger suggestions (`Control + Space` by default) in vscode to show. Not sure if we can make it automatically triggered after typing the space after `fn`. Another question is that I cannot figure out why `BLOCK_EXPR` need to be checked. A block expr directly inside a impl block should be invalid, and nested items will failed to locate impl block in specific offset and skip the suggestion. Now I simply removed it and no tests are broken. https://github.com/rust-analyzer/rust-analyzer/blob/4f91478e50dc5c2a87235e9be8bd91e3f62de4b4/crates/ide/src/completion/complete_trait_impl.rs#L109 Co-authored-by: oxalica <[email protected]>
| * | Complete trait impl immediately after type/const/fnoxalica2020-09-111-56/+119
| | |
* | | Merge #5985bors[bot]2020-09-141-1/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5985: Make MergeBehaviour configurable r=jonas-schievink a=Veykril This should make the newly implemented `MergeBehaviour` for import insertion configurable as roughly outlined in https://github.com/rust-analyzer/rust-analyzer/pull/5935#issuecomment-685834257. For the config name and the like I just picked what came to mind so that might be up for bikeshedding. Co-authored-by: Lukas Wirth <[email protected]>
| * | | Make MergeBehaviour configurableLukas Wirth2020-09-121-1/+3
| |/ /
* | | Merge #5971bors[bot]2020-09-132-0/+86
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5971: Implement async blocks r=flodiebold a=oxalica Fix #4018 @flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail: - Chalk doesn't support generator type yet. - Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 ) - The output type of async block should be known after type inference of the whole body. - We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`. - During the inference, the output type of async block can be temporary unknown and participate the later inference. `let a = async { None }; let _: i32 = a.await.unwrap();` So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type. And it really works now. Well, I still have some questions: - The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here. - Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type. Co-authored-by: oxalica <[email protected]>
| * | Fix type walking about type of async blockoxalica2020-09-111-0/+64
| | |
| * | Implement async blocksoxalica2020-09-101-0/+22
| | |
* | | Merge #5969bors[bot]2020-09-117-2/+339
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5969: Propose module name completion options r=jonas-schievink a=SomeoneToIgnore <img width="539" alt="image" src="https://user-images.githubusercontent.com/2690773/92663009-cb0aec00-f308-11ea-9ef5-1faa91518031.png"> Currently traverses the whole file set every time we try to complete the module, as discussed in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/mod.3C.7C.3E.20completion Co-authored-by: Kirill Bulatov <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 07:14:43 +0000