Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Merge #3513 | bors[bot] | 2020-03-09 | 1 | -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 Diebold | 2020-03-07 | 1 | -2/+2 |
| | | | | | | | | | | Two uses only needed the crate; one was wrong and should use the module from the scope instead. | ||||
| * | Try to complete within macros | Florian Diebold | 2020-03-07 | 1 | -0/+98 |
| | | |||||
* | | Handle visibility in method call completion | Florian Diebold | 2020-03-07 | 1 | -1/+37 |
|/ | |||||
* | fix completion for super::super:: | Josh Mcguigan | 2020-03-01 | 1 | -0/+39 |
| | |||||
* | Refactor primary IDE API | Aleksey Kladov | 2020-02-26 | 1 | -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 type | Aleksey Kladov | 2020-01-14 | 1 | -7/+10 |
| | |||||
* | Move impls_future to Type, where it belongs | Aleksey Kladov | 2020-01-14 | 1 | -1/+1 |
| | |||||
* | Use lang-items to resolve future trait | Aleksey Kladov | 2020-01-14 | 1 | -0/+1 |
| | |||||
* | visible_from -> is_visible_from | Florian Diebold | 2019-12-27 | 1 | -1/+1 |
| | |||||
* | Hide completions for private struct fields | Florian Diebold | 2019-12-26 | 1 | -1/+56 |
| | |||||
* | Remove one more Ty | Aleksey Kladov | 2019-12-08 | 1 | -1/+1 |
| | |||||
* | Add tests for checking the impl self type | Florian Diebold | 2019-12-02 | 1 | -0/+33 |
| | |||||
* | rename ra_ide_api -> ra_ide | Aleksey Kladov | 2019-11-27 | 1 | -0/+456 |