rust-analyzer icon indicating copy to clipboard operation
rust-analyzer copied to clipboard

Output type of aliased Fn trait object is not inferred correctly.

Open lucidfrontier45 opened this issue 3 years ago • 2 comments

  • rustc 1.63.0 (4b91a6ea7 2022-08-08)
  • rust-analyzer v0.3.1186

image

As is shown in the picture, the return type of dyn Fn trait objects is not correctly inferred. v in test_myfn_dyn and test_myfn2_dyn are also expected to be inferred as usize.

This may be related to https://github.com/rust-lang/rust-analyzer/issues/5057 but that was about directly writing dyn trait object, which works fine as the example of test_dyn_fn_trait_direct.

lucidfrontier45 avatar Sep 02 '22 00:09 lucidfrontier45

Interesting. Essentially, this is because chalk cannot prove Implemented(dyn Trait: Trait) given the following setup:

trait Base { type T; }
trait Trait: Base<T = usize> {}

Because of the rules described in https://github.com/rust-lang/chalk/issues/203, chalk needs to prove AliasEq(<dyn Trait as Base>::T = usize) only to fail as there's no clause for it.

@flodiebold Do you have any insights on this? I don't know chalk enough to tell if this is something chalk should be able to deduce by itself or if we need to give chalk more information, e.g. dyn for<Self> [Implemented(Self: Trait), AliasEq(<Self as Base>::T = usize)] for dyn Trait with the setup above whereas we currently only give dyn for<Self> [Implemented(Self: Trait)].

lowr avatar Sep 05 '22 04:09 lowr

Well, that seems wrong. It seems to me that associated type bindings should be implied, not required. It certainly wouldn't make any sense for us to add that clause, since that's what implied bounds / elaboration are for. I'd suggest opening a Chalk issue for it.

flodiebold avatar Sep 05 '22 16:09 flodiebold