aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src/completion
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | |
| * | Fix record pattern completionFlorian Diebold2020-03-073-1/+30
| | |
| * | Fix record literal completionFlorian Diebold2020-03-072-3/+33
| | |
| * | Fix range for postfix snippetsFlorian Diebold2020-03-071-2/+63
| | |
| * | Add more testsFlorian Diebold2020-03-072-0/+51
| | |
| * | Try to complete within macrosFlorian Diebold2020-03-074-27/+230
| |/
* | Handle visibility for assoc item path completion as wellFlorian Diebold2020-03-081-2/+65
| |
* | Handle visibility for path completion (not in all cases yet)Florian Diebold2020-03-081-4/+40
| |
* | Handle visibility in method call completionFlorian Diebold2020-03-071-1/+37
|/
* Don't creat public APIs with typosAleksey Kladov2020-03-061-1/+1
|
* Trigger parameter info automaticallyAleksey Kladov2020-03-062-0/+16
| | | | See https://github.com/Microsoft/vscode/issues/64023
* Feature flag for arg snippetsAleksey Kladov2020-03-061-4/+13
|
* Fix comment orderAleksey Kladov2020-03-061-2/+2
|
* Skip self param when completing methodsAleksey Kladov2020-03-041-13/+45
|
* Support function's completion snippetAvishay Matayev2020-03-042-14/+22
| | | | | | | Note that `detail` was replced with `function_signature` to avoid calling `from` on FunctionSignature twice. I didn't add new tests because the current ones seem enough.
* Fix completion snippet for reexported functionsFlorian Diebold2020-03-032-4/+54
| | | | Fixes #3356.
* Merge #3384bors[bot]2020-03-011-0/+39
|\ | | | | | | | | | | | | | | | | | | | | | | 3384: fix #2377 super::super::* r=flodiebold a=JoshMcguigan Thanks @matklad for the detailed explanation on #2377. I believe this fixes it. One thing I'm not sure about is you said the fix would involve changing `crates/ra_hir_def/src/path/lower/lower.rs`, but I only changed `crates/ra_hir_def/src/path/lower/lower_use.rs`. I'm not sure what kind of test code I'd have to write to expose the issue in `lower.rs`, but I'd be happy to add it if you are able to provide additional guidance. closes #2377 Co-authored-by: Josh Mcguigan <[email protected]>
| * fix completion for super::super::Josh Mcguigan2020-03-011-0/+39
| |
* | Rename ast::ImplBlock -> ast::ImplDefAleksey Kladov2020-02-292-32/+26
|/
* Refactor primary IDE APIAleksey Kladov2020-02-2610-60/+66
| | | | | | | | | | This introduces the new type -- Semantics. Semantics maps SyntaxNodes to various semantic info, such as type, name resolution or macro expansions. To do so, Semantics maintains a HashMap which maps every node it saw to the file from which the node originated. This is enough to get all the necessary hir bits just from syntax.
* Refactor how builtins are resolvedFlorian Diebold2020-02-211-6/+7
| | | | This fixes autocompletion suggesting e.g. self::usize.
* CleanupShotaro Yamada2020-02-191-5/+1
|
* More manual clippy fixesKirill Bulatov2020-02-182-6/+6
|
* Merge #3169bors[bot]2020-02-171-6/+95
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3169: Show record field names in Enum completion r=flodiebold a=adamrk Adresses https://github.com/rust-analyzer/rust-analyzer/issues/2947. Previously the details shown when autocompleting an Enum variant would look like the variant was a tuple even if it was a record: ![2020-02-16-15:59:32_crop](https://user-images.githubusercontent.com/16367467/74607233-64f21980-50d7-11ea-99db-e973e29c71d7.png) This change will show the names of the fields for a record and use curly braces instead of parentheses: ![2020-02-16-15:33:00_crop](https://user-images.githubusercontent.com/16367467/74607251-8ce17d00-50d7-11ea-9d4d-38d198a4aec0.png) This required exposing the type `adt::StructKind` from `ra_hir` and adding a function ``` kind(self, db: &impl HirDatabase) -> StructKind ``` in the `impl` of `EnumVariant`. There was also a previously existing function `is_unit(self, db: &impl HirDatabase) -> bool` for `EnumVariant` which I removed because it seemed redundant after adding `kind`. Co-authored-by: adamrk <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-03 15:44:54 +0000