Function trait objects output is not normalized

[smmalis37]

Normally when I use the ? operator, type inference is able to correctly see through it and mark variables with the Ok type of the Result. This seems to fall apart when used on a ref to a function trait object:

I would expect the type of r to be u8.

[lnicola]

Duplicate of #4281?

[flodiebold]

I assume the problem is simply inferring the result of f(), nothing related to the ? operator. It was mentioned in #4958, but I don't think we have a bug for it yet.

@lnicola no, that one's about the Fn impl being missing for function defs; this one is about normalizing <dyn FnOnce() -> T as FnOnce>::Output, which looks like it should work without problems; I'm not sure what's happening there. (Thinking about it, one theory might be that Chalk does all the well-known trait handling when encountering this goal and 'forgets' to generate the clauses from the dyn bounds... Another theory is that we're doing something wrong while lowering that type, which is also very possible.)

[smmalis37]

Ah, yeah this happens without ?. I was confused because I have other code that correctly normalizes Fn output, but what I didn't realize that that's on a generic over Fn, not a trait object. This seems to be something specific to trait object Fns.

[smmalis37]

This might have just been fixed? https://github.com/rust-analyzer/rust-analyzer/pull/4982/files#diff-2166f1133a31a1444822c765c18b9115L1760

[cynecx]

@smmalis37 Nope. I just checked, afaics it's still "broken".

[flodiebold]

It seems that's a bug in Chalk: rust-lang/chalk#567. (It was even simpler than my first theory -- any associated type bounds in dyn traits have this problem.)