16 Commits

Author SHA1 Message Date
Aleksey Kladov
dad8f1e064 Introduce completion test utils 2020-03-11 11:09:57 +01:00
Florian Diebold
adc7b8ea2d Fix completion with a partially unknown type
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.
2020-03-10 21:02:13 +01:00
bors[bot]
beb4f49541
Merge #3513
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 <flodiebold@gmail.com>
2020-03-09 08:56:58 +00:00
Florian Diebold
734e68da4c Handle visibility in method call completion 2020-03-07 23:03:56 +01:00
Florian Diebold
941a574409 Fix CompletionContext module field (by removing it)
Two uses only needed the crate; one was wrong and should use the module from the
scope instead.
2020-03-07 17:53:22 +01:00
Florian Diebold
24e98121d8 Try to complete within macros 2020-03-07 15:48:06 +01:00
Josh Mcguigan
0057d1e10d fix completion for super::super:: 2020-02-29 21:04:21 -08:00
Aleksey Kladov
c3a4c4429d Refactor primary IDE API
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.
2020-02-26 12:55:50 +01:00
Aleksey Kladov
a38540771f Move Type API to type 2020-01-14 14:42:52 +01:00
Aleksey Kladov
52e7f67128 Move impls_future to Type, where it belongs 2020-01-14 11:29:43 +01:00
Aleksey Kladov
0358f5fdeb Use lang-items to resolve future trait 2020-01-14 11:29:43 +01:00
Florian Diebold
9fd2c813ca visible_from -> is_visible_from 2019-12-27 11:25:04 +01:00
Florian Diebold
9e9c4be48a Hide completions for private struct fields 2019-12-26 16:23:40 +01:00
Aleksey Kladov
61c3887b70 Remove one more Ty 2019-12-08 17:50:43 +01:00
Florian Diebold
a5a07bde04 Add tests for checking the impl self type 2019-12-02 19:33:13 +01:00
Aleksey Kladov
757e593b25 rename ra_ide_api -> ra_ide 2019-11-27 21:35:06 +03:00