-
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
intra-doc-link resolution failures should not be reported for cross-crate re-exports #56922
Comments
…res, r=QuietMisdreavus deny intra-doc link resolution failures in libstd Fixes rust-lang#56693. Until we land a fix for the underlying issue (rust-lang#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
…res, r=QuietMisdreavus deny intra-doc link resolution failures in libstd Fixes rust-lang#56693. Until we land a fix for the underlying issue (rust-lang#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
…res, r=QuietMisdreavus deny intra-doc link resolution failures in libstd Fixes rust-lang#56693. Until we land a fix for the underlying issue (rust-lang#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
…res, r=QuietMisdreavus deny intra-doc link resolution failures in libstd Fixes rust-lang#56693. Until we land a fix for the underlying issue (rust-lang#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
Fix intra-doc link resolution failure on re-exporting libstd Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366). ```rust pub use std::*; ``` Until the underlying issue (rust-lang#56922) fixed, we can fix that so they don't propagate to downstream crates. Related: rust-lang#56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.) r? @QuietMisdreavus
This comment has been minimized.
This comment has been minimized.
Interesting, I was about to implement the opposite in #73101. I assume you'd still want the warning for additional documentation on the re-export? // crate a
// this will emit a warning when documenting a
/// [`BrokenLinkA`]
pub struct S;
// crate b
// this will give a warning for `BrokenLinkB`, but not for `BrokenLinkA`
/// Additional context: [`BrokenLinkB`]
pub use a::S; |
Yes, that seems reasonable to me. The goal here is to avoid reporting warnings to downstream crates that have no way to fix them. |
A possible reason not to do this: it's possible for links to fail only when re-exported, even without bugs in rustdoc: #75855 |
It turns out this was already implemented and has a test case: https://github.com/rust-lang/rust/blob/8fe438e632c0fe6a6d99f5096e21d9ab5d16fe3c/src/test/rustdoc/intra-link-extern-crate.rs. I'm still not sure it makes sense to do this but I don't feel super strongly about it. |
…r_new, r=jyn514 Link `new` method in `DefautHasher`s doc FIXME referenced rust-lang#56922 which was resolved r? @jyn514
…r_new, r=jyn514 Link `new` method in `DefautHasher`s doc FIXME referenced rust-lang#56922 which was resolved r? @jyn514
Discovered in #56693.
Currently, if a crate re-exports an item from another crate with resolution failures, then those resolution failures get reported for the original crate. Since the downstream crate has no way to fix the resolution failure in the upstream crate, it shouldn't be reported, much like capping lints.
As of this writing,
std::io::Error
has an intra-link resolution failure in one of its impls. So, the following code triggers the issue.A fix for this issue should take care to still report failures for re-exports within the same crate.
cc #43466
The text was updated successfully, but these errors were encountered: