aboutsummaryrefslogtreecommitdiff
path: root/crates/ide
Commit message (Collapse)AuthorAgeFilesLines
...
* 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]>
| * | | Adjust the test commentKirill Bulatov2020-09-111-9/+16
| | | |
| * | | One more testKirill Bulatov2020-09-091-0/+15
| | | |
| * | | Rename the method to avoid false promisesKirill Bulatov2020-09-091-5/+5
| | | |
| * | | Fix the testsKirill Bulatov2020-09-095-7/+9
| | | |
| * | | Add testsKirill Bulatov2020-09-091-0/+153
| | | |
| * | | Properly handle mod.rs importsKirill Bulatov2020-09-091-47/+40
| | | |
| * | | Complete semicolon when neededKirill Bulatov2020-09-096-26/+30
| | | |
| * | | Properly reacto to keywordsKirill Bulatov2020-09-096-4/+28
| | | |
| * | | Less false positive completion candidatesKirill Bulatov2020-09-091-44/+59
| | | |
| * | | Properly handle nested submodules in the same fileKirill Bulatov2020-09-091-70/+79
| | | |
| * | | Move most of the logic into the completion moduleKirill Bulatov2020-09-092-23/+98
| | | |
| * | | Finally cretae the mod completion moduleKirill Bulatov2020-09-093-17/+42
| | | |
| * | | Properly handle special cases (binaries, mod.rs)Kirill Bulatov2020-09-091-3/+1
| | | |
| * | | Exclude special filesKirill Bulatov2020-09-091-3/+0
| | | |
| * | | Happy path implementedKirill Bulatov2020-09-091-1/+1
| | | |
| * | | Better APIKirill Bulatov2020-09-091-5/+4
| | | |
| * | | First steps for mod<|> completionKirill Bulatov2020-09-091-2/+23
| |/ /
* | | Fix handling of consuming self, refactor shared logic into a single functionPaul Daniel Faria2020-09-062-30/+34
| | |
* | | Add consuming modifier to lvalues that are passed by value and not CopyPaul Daniel Faria2020-09-063-14/+53
|/ /
* / Document VS Code setting needed for on-typing assistsAramis Razzaghipour2020-09-011-0/+8
|/
* :arrow_up: expect-testAleksey Kladov2020-08-289-8/+8
|
* MinorAleksey Kladov2020-08-271-1/+2
|
* Tease apart orthogonal concerns in markdown link rewritingAleksey Kladov2020-08-263-15/+231
| | | | | | | | | | | | `hir` should know nothing about URLs, markdown and html. It should only be able to: * resolve stringy path from documentation * generate canonical stringy path for a def In contrast, link rewriting should not care about semantics of paths and names resolution, and should be concern only with text mangling bits.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 10:48:51 +0000