aboutsummaryrefslogtreecommitdiff
path: root/crates/ide
Commit message (Collapse)AuthorAgeFilesLines
...
* | 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.
* Cleanup hover links testsAleksey Kladov2020-08-261-88/+74
|
* Improve support for code block attributesLeón Orell Valerian Liehr2020-08-261-9/+99
|
* Complete `pub` in fieldsAleksey Kladov2020-08-254-7/+36
|
* Use the same abstraction for attrs and docsAleksey Kladov2020-08-253-3/+3
| | | | | Doc comments *are* attributes, so there's no reason to have two crates here.
* Merge remote-tracking branch 'upstream/master' into 503-hover-doc-linksZac Pullar-Strecker2020-08-253-15/+36
|\
| * Merge #4776bors[bot]2020-08-241-11/+12
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | 4776: Do a weekly minor publish to crates.io r=matklad a=pksunkara This is the same system I set up on Chalk repo. Every week it creates a new minor version, pushes it to github and then deploys it to crates.io. Co-authored-by: Pavan Kumar Sunkara <[email protected]>
| | * Add description for crates that will be publishedPavan Kumar Sunkara2020-08-241-0/+1
| | |
| | * Add version to deps in cargo.tomlPavan Kumar Sunkara2020-08-241-11/+11
| | |
| * | Omit lenses for not runnable doctestsKirill Bulatov2020-08-222-4/+24
| |/
* | Renames, comments, and dead code removalZac Pullar-Strecker2020-08-241-1/+3
| |
* | Merge remote-tracking branch 'upstream/master' into 503-hover-doc-linksZac Pullar-Strecker2020-08-245-56/+625
|/
* Merge #5823bors[bot]2020-08-222-8/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5823: Don't underline function definition if self is &mut r=Nashenas88 a=matklad The self is right there, and is already underlined, so it makes little sense to emit even more underlines. before: ![before](https://user-images.githubusercontent.com/1711539/90672843-0d379500-e257-11ea-840f-b0caed4410f1.png) after: ![after](https://user-images.githubusercontent.com/1711539/90672840-0c9efe80-e257-11ea-9739-23af433841c6.png) Co-authored-by: Aleksey Kladov <[email protected]>
| * Don't underline function definition if self is &mutAleksey Kladov2020-08-192-8/+2
| | | | | | | | | | The self is right there, and is already underlined, so it makes little sense to emit even more underlines.
* | :arrow_up: ungrammarAleksey Kladov2020-08-212-2/+3
| |
* | Switch to expect_test from crates.ioAleksey Kladov2020-08-2124-24/+24
|/
* Remove dead codeAleksey Kladov2020-08-191-25/+15
|
* Future proof find-usages APIAleksey Kladov2020-08-191-1/+3
| | | | | | We might want to provide more efficient impls for check if usages exist, limiting the search, filtering and cancellation, so let's violate YAGNI a bit here.
* Apply couple of rule of thumbs to simplify highlighting codeAleksey Kladov2020-08-191-19/+16
| | | | | | | | | | | | | | | | | Main one: instead of adding a parameter to function to handle special case, make the caller handle it. Second main one: make sure that function does a reasonable thing. `highlight_def` picks a color for def, *regardless* of the context the def is use. Feeding an info from the call-site muddies the responsibilities here. Minor smells, flagging the function as having space for improvement in the first place: * many parameters, some of which are set as constants on most call-sites (introduce severalfunction instad) * boolean param (add two functions instead)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 21:35:06 +0000