aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src/completion/complete_dot.rs
Commit message (Collapse)AuthorAgeFilesLines
* Introduce completion test utilsAleksey Kladov2020-03-111-1/+1
|
* 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.
* Merge #3513bors[bot]2020-03-091-2/+100
|\ | | | | | | | | | | | | | | | | | | | | 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]>
| * Fix CompletionContext module field (by removing it)Florian Diebold2020-03-071-2/+2
| | | | | | | | | | Two uses only needed the crate; one was wrong and should use the module from the scope instead.
| * Try to complete within macrosFlorian Diebold2020-03-071-0/+98
| |
* | Handle visibility in method call completionFlorian Diebold2020-03-071-1/+37
|/
* fix completion for super::super::Josh Mcguigan2020-03-011-0/+39
|
* Refactor primary IDE APIAleksey Kladov2020-02-261-2/+2
| | | | | | | | | | 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.
* Move Type API to typeAleksey Kladov2020-01-141-7/+10
|
* Move impls_future to Type, where it belongsAleksey Kladov2020-01-141-1/+1
|
* Use lang-items to resolve future traitAleksey Kladov2020-01-141-0/+1
|
* visible_from -> is_visible_fromFlorian Diebold2019-12-271-1/+1
|
* Hide completions for private struct fieldsFlorian Diebold2019-12-261-1/+56
|
* Remove one more TyAleksey Kladov2019-12-081-1/+1
|
* Add tests for checking the impl self typeFlorian Diebold2019-12-021-0/+33
|
* rename ra_ide_api -> ra_ideAleksey Kladov2019-11-271-0/+456