-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rustdoc doesn't see trait implementations inside of functions #41480
Comments
The scope of the implementation is only inside the function and so cannot be used outside of it and so shouldn't be documented. Also, macro != functions. If you make an implementation inside a macro, it's documented. Closing it then, don't hesitate to reopen it if I missed something. |
No, this is exactly the problem I was referring to -
I referred to macro only because I'm using them inside of such function to generate both |
To enhance the example above: pub struct S;
pub fn a() {
impl From<u8> for S {
fn from(_: u8) -> S {
S
}
}
}
fn main() {
let s = S::from(10u8);
} ^^ |
(GitHub doesn't allow non-members to reopen issues closed by others.) |
Indeed, thanks for reopening this! |
Thanks for reopening it @petrochenkov. @RReverser: That's completely crazy. Another example just for the fun: pub struct S;
trait Foo {
fn foo(&self) {}
}
pub fn a() {
impl Foo for S {
}
}
fn main() {
S.foo();
} So rustdoc should document these implementations as well. Thanks for opening the issue! |
Got bit by this. rustdoc were simply unable to find a trait implementation defined in a function which |
I've opened #53162 to fix this. |
…=GuillaumeGomez rustdoc: collect trait impls as an early pass Fixes #52545, fixes #41480, fixes #36922 Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to #53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display. But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
…en-trait, r=GuillaumeGomez rustdoc: collect trait impls as an early pass Fixes rust-lang#52545, fixes rust-lang#41480, fixes rust-lang#36922 Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to rust-lang#53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display. But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
…en-trait, r=GuillaumeGomez rustdoc: collect trait impls as an early pass Fixes rust-lang#52545, fixes rust-lang#41480, fixes rust-lang#36922 Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to rust-lang#53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display. But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
…=GuillaumeGomez rustdoc: collect trait impls as an early pass Fixes #52545, fixes #41480, fixes #36922 Right now, rustdoc pulls all its impl information by scanning a crate's HIR for any items it finds. However, it doesn't recurse into anything other than modules, preventing it from seeing trait impls that may be inside things like functions or consts. Thanks to #53002, now these items actually *exist* for rustdoc to see, but they still weren't getting collected for display. But there was a secret. Whenever we pull in an item from another crate, we don't have any of its impls in the local HIR, so instead we ask the compiler for *everything* and filter out after the fact. This process is only triggered if there's a cross-crate re-export in the crate being documented, which can sometimes leave this info out of the docs. This PR instead moves this collection into an early pass, which occurs immediately after crate cleaning, so that that collection occurs regardless. In addition, by including the HIR's own `trait_impls` in addition to the existing `all_trait_implementations` calls, we can collect all these tricky trait impls without having to scan for them!
It's possible to define trait implementations inside of functions in Rust. This is useful not too often, but particularly nice if you have a macro that both defines trait implementation and calls some initialization for a given type.
Anyway, the following code is valid in Rust itself:
But Rustdoc doesn't generate documentation for a given trait, despite it being visible to Rust itself, and being immediately available and unique across entire crate.
I can move
impl
out of the function and then it gets seen by Rustdoc, but this is rather inconvenient whenimpl
is generated as part of a bigger macro.The text was updated successfully, but these errors were encountered: