diff options
author | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-04-14 15:06:48 +0100 |
---|---|---|
committer | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-04-14 15:06:48 +0100 |
commit | fcbd0269545f2b6687a64a868654c74f876b7851 (patch) | |
tree | cb439cc77b5445f00cda86e932c199cb69ae47d6 /crates/ra_ide_api/src/completion/complete_scope.rs | |
parent | 23b876bc3b00c53ce24b8a99b4f4bf190fc6300e (diff) | |
parent | 8bcbcc454cbb48b897083c122566c0b4c2b780aa (diff) |
Merge #1120
1120: More trait infrastructure r=matklad a=flodiebold
This adds enough trait infrastructure to be able to make some deductions about type variables when resolving trait methods, while at the same time doing as little as possible that will be later replaced by Chalk :smile:
E.g. (as the tests show) if we have
```rust
trait Trait<T> { fn method(self) -> T }
impl Trait<u32> for S {}
...
S.method()
```
we can infer that the return type is `u32`. On the other hand the unification logic is so primitive that we can't handle e.g. `impl<T> Trait<T> for S<T>`.
It's all quite hacky, I plan to refactor the parts that will stay, while hopefully the other parts will be replaced soon :slightly_smiling_face: In particular, we need to handle 'containers' (impls and trait defs) more cleanly, and I need to reorganize the method resolution / type inference code...
Co-authored-by: Florian Diebold <[email protected]>
Diffstat (limited to 'crates/ra_ide_api/src/completion/complete_scope.rs')
0 files changed, 0 insertions, 0 deletions