Stream: t-compiler/wg-rls-2.0

Topic: Intrinsic methods with trait constraints


Sebastian Zimmer (Nov 02 2019 at 22:22, on Zulip):

I have never worked on rust analyser before, but I ran into this issue https://github.com/rust-analyzer/rust-analyzer/issues/2138 on a personal project so I figured I'd try to fix it myself. It seems to be pretty easy to fix the precise sample in that issue, but it looks harder to fix the problem I was having myself.

           trait Foo {
                fn foo(&self);
            }
            trait Bar {
                fn bar(&self);
            }
            struct X();
            impl Foo for X {
                fn foo(&self) {}
            }

            struct Wrapper<T>(T);
            impl<T: Foo> Wrapper<T> {
                fn wrapper_foo(&self) { self.0.foo() }
            }
            impl<T: Bar> Wrapper<T> {
                fn wrapper_bar(&self) { self.0.bar() }
            }
            fn main() {
                let wrapper = Wrapper(X());
                let x = wrapper.<|>
            }

(The completions should contain wrapper_foo but not wrapper_bar). The way that inherent methods work atm seems weird to me, wouldn't it make more sense if each inherent impl block created a trait? That way chalk could do the work of determining which inherent impl blocks apply at a given call site.

Florian Diebold (Nov 02 2019 at 22:35, on Zulip):

That might work to basically avoid having to do the unification and checking the where clauses ourselves, but note that inherent methods behave somewhat differently from traits, e.g. they don't need to be in scope and are chosen with priority over traits, so they need special handling anyway; and doing the unification properly isn't that hard either, so I don't feel like it would be worth it

Florian Diebold (Nov 02 2019 at 22:36, on Zulip):

also note that I'm currently working on refactoring method resolution as well to get the priority order really correct

Sebastian Zimmer (Nov 03 2019 at 19:54, on Zulip):

I've got a mostly working implementation of this now, but it breaks the test obligation_from_impl_clause. I don't understand how this test is supposed to work though, I get error E0207 when I try to compile it with rustc.

Florian Diebold (Nov 03 2019 at 20:12, on Zulip):

here's a slightly more complicated version that compiles in rustc: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=351a23ed72c6de64f600cc7c190a6faf

Last update: Nov 12 2019 at 16:15UTC