rustdoc: explicit marker trait impl bounds are not simplified

[Nemo157]

Rustdoc currently renders automatic and explicit marker trait implementation bounds differently, for automatic implementations the bounds are simplified down to their most fundamental requirements, while explicit implementations show exactly what is specified.

As an example, here are two identically defined structs (Bar and Baz), one uses the automatic implementation for Send while the other has the same implementation explicitly defined, in both cases the direct requirement is Foo<T>: Send which can be simplified down to T: Send by looking at the bounds on Foo:

pub struct Foo<T>(T);

pub struct Bar<T>(Foo<T>);

pub struct Baz<T>(Foo<T>);

unsafe impl<T> Send for Baz<T> where Foo<T>: Send {}

and the associated impl Send renderings:

This will become more relevant if RFC 2145 is ever implemented, that should allow bounds to refer to private types in which case there is no way to go from the impl Send for Baz in the docs to see what the actual requirements are (but it is already possible to simulate that today if Foo is moved into a private module).

This is also an issue for the proc-macro in https://github.com/taiki-e/pin-project (cc @taiki-e), that produces an explicit implementation for Unpin that must refer to the field types so that it can work generically for any struct.

[Aaron1011]

Isn't this the correct behavior?

With the automatically generated impl, there's no user-written impl for Rustdoc to render. When a user impl is provided, however, I think it makes sense to render exactly what they wrote.

[Nemo157]

If there are usecases for showing exactly how the impl was written, then maybe there could be a flag to opt-in to the behaviour of the automatically generated impl?

I have the extended problem I mentioned where it's impossible to determine what the bounds are from the docs in this crate, the Unpin impl depends on a "private" type so you would have to read the source to see what it is (and even worse there is no actual Unpin implementation on that type, it is also generated by a proc-macro so you would have to know how that macro works).

[taiki-e]

If the bounds can be simplified in any of the following cases, I think the issues with pin-project can be resolved.

1. A structure in which #[doc(hidden)] is used.
2. A structure generated by proc-macro.