Rustdoc cannot infer type when using type_alias_impl_trait, while rustc works

[bjorn3]

#![feature(type_alias_impl_trait)]

pub trait Backend {}

impl Backend for () {}

pub struct Module<T>(T);

pub type BackendImpl = impl Backend;

pub fn make_module() -> Module<BackendImpl> {
    Module(())
}

$ rustc -V
rustc 1.38.0 (625451e37 2019-09-23)
$ cargo doc
error[E0282]: type annotations needed
  --> src/main.rs:13:1
   |
13 | pub type BackendImpl = impl Backend<Product: std::any::Any>;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type

error: aborting due to previous error
$ cargo build

[bjorn3]

@rustbot modify labels: +requires-nightly +F-type_alias_impl_trait

[GuillaumeGomez]

That is... interesting.

[bjorn3]

Forgot to add T-rustdoc :)

[Aaron1011]

This looks like an issue in should_ignore_fn, which is used by Rustdoc to determine which functions should have their bodies replaced by loops.

This check is done on the AST. I think what's happening is that we detect BackendImpl (since it appears as a generic argument to Module), but are unable to determine that BackendImpl is an opaque type (since we haven't resolved paths yet).

I'm not familiar enough with the various phases of the compiler to know if it would be possible to do this check later, once we have ty::Tys available for the function signature (e.g. resolved types).

We may have to largely give up on this check, and actually compile the bodies of most functions. That could mean a fairly large regression in doc build times - but if we can't come up with a way to detect which functions might constrain opaque types, I don't think we have another option.

[Aaron1011]

Actually, we might be able to check for the presence any impl Trait definitions within a parent scope of the function. This would have a large number of false positives (any impl Traits at the crate root would cause every function to be flagged as 'may define an opaque type'), but it would be better than nothing.

[clarfonthey]

Also ran into this bug, came up with another example:

#![feature(type_alias_impl_trait)]
use core::iter::empty;
type Test = impl Iterator<Item = ()>;
fn test() -> Test {
    empty()
}

Rustdoc error:

error[E0277]: `()` is not an iterator
 --> src/lib.rs:3:1
  |
3 | type Test = impl Iterator<Item = ()>;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `()` is not an iterator
  |
  = help: the trait `std::iter::Iterator` is not implemented for `()`
  = note: the return type of a function must have a statically known size

[GuillaumeGomez]

@clarfon Nice one, thanks!

@ollie27 Didn't you fixed something close to this recently? (I might be wrong though...)

[ollie27]

@ollie27 Didn't you fixed something close to this recently? (I might be wrong though...)

I don't think so, no.

[jonhoo]

Here's another instance of this bug:

#![feature(type_alias_impl_trait)]
use std::future::Future;

trait Foo {
    type X: Future<Output = ()>;
    fn x() -> Self::X;
}

impl Foo for () {
    type X = impl Future<Output = ()>;
    fn x() -> Self::X {
        async {}
    }
}