aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src/completion
Commit message (Collapse)AuthorAgeFilesLines
...
* A more precise panic macroAleksey Kladov2020-04-071-1/+1
|
* Don't insert !() if there's already someAleksey Kladov2020-04-072-3/+44
|
* Reorder importsAleksey Kladov2020-04-071-3/+6
|
* Better naming for scope completionAleksey Kladov2020-04-072-2/+2
|
* Better naming for path completionAleksey Kladov2020-04-072-0/+0
|
* Fix unnecessary braces warningsLaurențiu Nicola2020-04-062-5/+5
|
* Add parens for enumsAleksey Kladov2020-04-034-46/+175
|
* Generalize call parenthesis insertionAleksey Kladov2020-04-031-27/+46
|
* Remove the second code-path for completing names in patternsAleksey Kladov2020-04-033-70/+28
|
* Unite record completion logic into a single moduleKirill Bulatov2020-04-013-386/+411
|
* Split draftKirill Bulatov2020-04-012-59/+25
|
* Complete only missing fields in patsKirill Bulatov2020-04-011-1/+62
|
* Better names for config structsAleksey Kladov2020-03-314-14/+14
|
* Start stdxAleksey Kladov2020-03-281-24/+21
| | | | This crate will hold everything to small to be worth publishing
* Align namingAleksey Kladov2020-03-241-1/+1
|
* Merge #3694bors[bot]2020-03-241-1/+61
|\ | | | | | | | | | | | | | | 3694: Complete only missing fields r=matklad a=SomeoneToIgnore Co-authored-by: Kirill Bulatov <[email protected]>
| * Code review fixesKirill Bulatov2020-03-241-3/+4
| | | | | | | | Co-Authored-By: Aleksey Kladov <[email protected]>
| * Complete only missing fieldsKirill Bulatov2020-03-231-1/+60
| |
* | Consider references when applying postfix completionsKirill Bulatov2020-03-231-17/+123
|/
* Remove constSteffen Lyngbaek2020-03-193-6/+48
| | | | | - Add test for @ matching - Address comments
* Fixes to more accurately give complete_scope completionsSteffen Lyngbaek2020-03-193-15/+38
| | | | | | | - Exclude const, static, functions form is_pat_binding_and_path (there might be more?) - Add a check to filter out Record Fields - Fix tests
* - Exclude Local Scope for BindPatsSteffen Lyngbaek2020-03-192-58/+16
| | | | | - Exclude BindPats with @ or ref - Remove outdated test and add one testing for ref
* Completition for type name? #3418Steffen Lyngbaek2020-03-192-3/+120
| | | | | | | | Iterate through TupleStructPat's until a MatchArm if one exists. Store in a new is_pat_bind_and_path bool and allow the `complete_scope` to find matches. Added some tests to ensure it works in simple and nested cases.
* Add test, remove printlnsFlorian Diebold2020-03-161-0/+53
|
* Get tests workingFlorian Diebold2020-03-162-2/+13
|
* wipFlorian Diebold2020-03-162-4/+13
|
* Attempt to implement ranking of rules when none matches perfectly (wip)Florian Diebold2020-03-161-1/+38
|
* Make MBE expansion more resilient (WIP)Florian Diebold2020-03-161-0/+37
|
* Fix completion of trait itemsFlorian Diebold2020-03-141-0/+32
| | | | Trait items should be public by default.
* Don't use generic DB where a concrete one will doAleksey Kladov2020-03-131-3/+6
|
* Fix completion of HashMap::newFlorian Diebold2020-03-132-2/+36
| | | | | | | | | | | | | | | The `ty` function in code_model returned the type with placeholders for type parameters. That's nice for printing, but not good for completion, because placeholders won't unify with anything else: So the type we got for `HashMap` was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`, so the `new` method wasn't shown. Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does unify with the impl type. Maybe we should just expose this properly as variables though, i.e. we'd return something like `exists<type, type, type> HashMap<?0, ?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more correctly.)
* Restore cargo-fmt gatingAleksey Kladov2020-03-131-1/+0
|
* Merge #3553bors[bot]2020-03-131-0/+39
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 3553: Completions do not show for function with same name as mod r=matklad a=JoshMcguigan fixes #3444 I've added a test case in `crates/ra_ide/src/completion/complete_path.rs` which verifies the described behavior in #3444. Digging in, I found that [the module scope iterator](https://github.com/JoshMcguigan/rust-analyzer/blob/ba62d8bd1ce8a68b8d21aaf89ae1ea6787f18366/crates/ra_ide/src/completion/complete_path.rs#L22) only provides the module `z`, and does not provide the function `z` (although if I name the function something else then it does show up here). I thought perhaps the name wasn't being properly resolved, but I added a test in `crates/ra_hir_def/src/nameres/tests.rs` which seems to suggest that it is? I've tried to figure out how to bridge the gap between these two tests (one passing, one failing) to see where the function `z` is being dropped, but to this point I haven't been able to track it down. Any pointers on where I might look for this? Co-authored-by: Josh Mcguigan <[email protected]>
| * fix issue 3444Josh Mcguigan2020-03-131-0/+39
| |
* | Add test for completion of unresolved itemsAleksey Kladov2020-03-131-0/+34
| |
* | Fix completion testsAleksey Kladov2020-03-123-0/+12
|/
* Introduce completion test utilsAleksey Kladov2020-03-1115-46/+47
|
* Add a test for disabled argument snippetsAleksey Kladov2020-03-112-4/+56
|
* Fix completion with a partially unknown typeFlorian Diebold2020-03-101-0/+31
| | | | | | | | | | | | | | To test whether the receiver type matches for the impl, we unify the given self type (in this case `HashSet<{unknown}>`) with the self type of the impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't be unified with the variables in those places. So we got a receiver type that was different from the expected one, and concluded the impl doesn't match. The fix is slightly hacky; if after the unification, our variables are still there, we make them fall back to Unknown. This does make some sense though, since we don't want to 'leak' the variables. Fixes #3547.
* Pull completion options up to the rust-analyzerAleksey Kladov2020-03-101-4/+1
|
* Introduce CompletionOptionsAleksey Kladov2020-03-104-14/+14
|
* Merge pull request #3506 from slyngbaek/3183Aleksey Kladov2020-03-101-16/+128
|\ | | | | Next steps in assoc item completion #3183
| * Switch to explicit offsets for impl_defSteffen Lyngbaek2020-03-091-26/+11
| | | | | | | | Blacklists are prone to more errors
| * Clean up completion matching.Steffen Lyngbaek2020-03-091-24/+53
| | | | | | | | - Add test to ensure nested completions don't happen
| * Don't allow nested completionsSteffen Lyngbaek2020-03-081-13/+18
| |
| * Next steps in assoc item completion #3183Steffen Lyngbaek2020-03-071-6/+99
| | | | | | | | | | | | | | | | Allow trait autocompletions for unimplemented associated fn's, types, and consts without using explicit keywords before hand (fn, type, const). The sequel to #3108.
* | Merge #3513bors[bot]2020-03-099-36/+421
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3513: Completion in macros r=matklad a=flodiebold I experimented a bit with completion in macros. It's kind of working, but there are a lot of rough edges. - I'm trying to expand the macro call with the inserted fake token. This requires some hacky additions on the HIR level to be able to do "hypothetical" expansions. There should probably be a nicer API for this, if we want to do it this way. I'm not sure whether it's worth it, because we still can't do a lot if the original macro call didn't expand in nearly the same way. E.g. if we have something like `println!("", x<|>)` the expansions will look the same and everything is fine; but in that case we could maybe have achieved the same result in a simpler way. If we have something like `m!(<|>)` where `m!()` doesn't even expand or expands to something very different, we don't really know what to do anyway. - Relatedly, there are a lot of cases where this doesn't work because either the original call or the hypothetical call doesn't expand. E.g. if we have `m!(x.<|>)` the original token tree doesn't parse as an expression; if we have `m!(match x { <|> })` the hypothetical token tree doesn't parse. It would be nice if we could have better error recovery in these cases. Co-authored-by: Florian Diebold <[email protected]>
| * | Move hypothetical expansion to hir_expandFlorian Diebold2020-03-081-1/+5
| | |
| * | Fix CompletionContext module field (by removing it)Florian Diebold2020-03-073-8/+6
| | | | | | | | | | | | | | | Two uses only needed the crate; one was wrong and should use the module from the scope instead.
| * | Add some sanity checksFlorian Diebold2020-03-071-1/+10
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-23 01:57:29 +0000