1128: A touch of type-safety r=matklad a=matklad
Note that we intentionally don't use `Either` from crates.io: I like A/B naming more then left/rigth, I feel like we might need Either3 with C at some point, and I'd love the ability to write inherent impls
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1122: Add explicit type assist. r=matklad a=marcogroppo
This assist can be used to specify the explicit type in let statements. For example `let num = 1;` becomes `let num: i32 = 1;`.
The assist is applicable only if the inferred type is fully known.
Co-authored-by: Marco Groppo <marco.groppo@gmail.com>
1110: Introduce display module and implement new FunctionSignature for CallInfo's r=matklad a=vipentti
This introduces a new module `display` in `ra_ide_api` that contains UI-related things, in addition this refactors CallInfo's function signatures into a new `FunctionSignature` type, which implements `Display` and can be converted into `lsp_types::SignatureInformation` in the `conv` layer.
Currently only `CallInfo` uses the `FunctionSignature` directly, but `function_label` now uses the same signature and returns it as a string, using the `Display` implementation.
This also fixes#960
I think this similar structure could be applied to other UI-displayable items, so instead of the `ra_ide_api` returning `Strings` we could return some intermediate structures that can be converted into a UI-displayable `String` easily, but that could also provide some additional information.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
1105: [WIP] Implement ra_mbe meta variables support r=matklad a=edwin0cheng
This PR implements the following meta variable support in `ra_mba` crate (issue #720):
- [x] `path`
- [ ] `expr`
- [ ] `ty`
- [ ] `pat`
- [ ] `stmt`
- [ ] `block`
- [ ] `meta`
- [ ] `item`
*Implementation Details*
In the macro expanding lhs phase, if we see a meta variable type, we try to create a `tt:TokenTree` from the remaining input. And then we use a special set of `ra_parser` to parse it to `SyntaxNode`.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1103: Array inference r=flodiebold a=Lapz
Fixes the final item in #394. The only problem is that infering the repeat cause some types to be infered twices.
i.e
```rust
fn test() {
let y = unknown;
[y, &y];
}
```
results in the following diff:
```diff
[11; 48) '{ ...&y]; }': ()
[21; 22) 'y': &{unknown}
[25; 32) 'unknown': &{unknown}
-[38; 45) '[y, &y]': [&&{unknown}]
+[38; 45) '[y, &y]': [&&{unknown};usize]
[39; 40) 'y': &{unknown}
+[39; 40) 'y': &{unknown}
[42; 44) '&y': &&{unknown}
[43; 44) 'y': &{unknown}
```
Should the code produce two inference results for 'y' and if not could any tell me what needs to change.
Co-authored-by: Lenard Pratt <l3np27@gmail.com>
