While working with the embedded-hal crates for STM32 boards, I ran into a curious issue where the "Implementations on Foreign Types" section lists pretty much what it says on the tin, but the foreign types in question do not conversely list all the traits that are 'foreignly' implemented on them.
While understandable for std types, since the std library is externally documented and thus can't be modified to reflect this fact, this makes a lot less sense when eg. generating documentation for a project through cargo doc; and in fact, it can make it very difficult when working with svd2rust-based crates to determine what you can do with eg. GPIO pins.
The generated documentation is included, but can also be found here. You can see that the other::Foo trait has an impl Foo for Baz under implementations on foreign types, but conversely the Baz struct does not list the Foo trait anywhere.
Ideally, this should work bidirectionally, and the Foo trait should be listed on Baz (eg. as a 'foreignly implemented trait').
While working with the embedded-hal crates for STM32 boards, I ran into a curious issue where the "Implementations on Foreign Types" section lists pretty much what it says on the tin, but the foreign types in question do not conversely list all the traits that are 'foreignly' implemented on them.
While understandable for
std
types, since thestd
library is externally documented and thus can't be modified to reflect this fact, this makes a lot less sense when eg. generating documentation for a project throughcargo doc
; and in fact, it can make it very difficult when working withsvd2rust
-based crates to determine what you can do with eg. GPIO pins.I've reproduced a small testcase of the problem here: https://git.cryto.net/joepie91/rustdoc-foreign-traits-bugcase
The generated documentation is included, but can also be found here. You can see that the
other::Foo
trait has animpl Foo for Baz
under implementations on foreign types, but conversely theBaz
struct does not list theFoo
trait anywhere.Ideally, this should work bidirectionally, and the
Foo
trait should be listed onBaz
(eg. as a 'foreignly implemented trait').