Skip to content
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 links to private types on private items generate a warning #74134

Closed
dennis-hamester opened this issue Jul 7, 2020 · 6 comments · Fixed by #74147
Closed

Rustdoc links to private types on private items generate a warning #74134

dennis-hamester opened this issue Jul 7, 2020 · 6 comments · Fixed by #74147
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@dennis-hamester
Copy link
Contributor

With #72771 merged (current nightly, e.g. 1.46.0-nightly (0c03aee8b 2020-07-05)) , the following code now produces a warning:

struct Private;

pub struct Public {
    /// A private field with a [`Private`] type.
    private: Private,
}

This triggers intra_doc_link_resolution_failure:

warning: `[Private]` public documentation for `private` links to a private item
 --> src/lib.rs:4:12
  |
4 |     /// A [`Private`] field.
  |            ^^^^^^^^^ this item is private
  |
  = note: `#[warn(intra_doc_link_resolution_failure)]` on by default

But rustdoc never actually generates any links to Private, because it wasn't run with --document-private-items. In my opinion it shouldn't emit warning in this case, because documenting the internals can be very useful to contributors or even future me when --document-private-items is used.

There has already been some discussion at the end of #72771, which is where I asked first about whether this change was intentional.

@dennis-hamester dennis-hamester added the C-bug Category: This is a bug. label Jul 7, 2020
@jyn514
Copy link
Member

jyn514 commented Jul 7, 2020

@rustbot modify labels: T-rustdoc A-intra-doc-links

@rustbot rustbot added A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 7, 2020
@dennis-hamester
Copy link
Contributor Author

Assuming the consensus is that rustdoc shouldn't warn in this case, would an additional check against the item's visibility be correct? Like:

--- a/src/librustdoc/passes/collect_intra_doc_links.rs
+++ b/src/librustdoc/passes/collect_intra_doc_links.rs
@@ -773,6 +773,7 @@ impl<'a, 'tcx> DocFolder for LinkCollector<'a, 'tcx> {
 
                     let hir_id = self.cx.tcx.hir().as_local_hir_id(local);
                     if !self.cx.tcx.privacy_access_levels(LOCAL_CRATE).is_exported(hir_id)
+                        && (item.visibility == Visibility::Public)
                         && !self.cx.render_options.document_private
                     {
                         let item_name = item.name.as_deref().unwrap_or("<unknown>");

That certainly gets rid of the warning in my case, but I'm unsure about the other variants of Visibility and all the other kinds of things item can refer to.

@jyn514
Copy link
Member

jyn514 commented Jul 7, 2020

That looks reasonable to me. Could you make a PR with that change and a few test cases?

@dennis-hamester
Copy link
Contributor Author

Wouldn't the check like I changed it then only catch cases like this:

struct Private;

pub struct Public {
    /// A private field with a [`Private`] type.
    pub public: Private,
}

But that already triggers E0446 anyway:

error[E0446]: private type `Private` in public interface
 --> src/lib.rs:5:5
  |
5 |     pub public: Private,
  |     ^^^^^^^^^^^^^^^^^^^^ can't leak private type

@jyn514
Copy link
Member

jyn514 commented Jul 7, 2020

@dennis-hamester the link is entirely separate from the type of the field. You could have

pub struct Public {
    /// See also [`Private`] type
    pub public: u32,
}

in which case there would be no error but the warning should still be generated.

@dennis-hamester
Copy link
Contributor Author

@jyn514 Ah, yes of course, thanks for pointing that out :)

I'll open a PR then.

dennis-hamester added a commit to dennis-hamester/aldrin that referenced this issue Jul 9, 2020
This works around issue #74134 in rustdoc and should be reverted when PR #74147
is merged and available in a nightly.

 - #74134: rust-lang/rust#74134
 - #74147: rust-lang/rust#74147
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 13, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 13, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 13, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 13, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 14, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 14, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 14, 2020
…jyn514

rustdoc: Allow linking from private items to private types

Fixes rust-lang#74134

After PR rust-lang#72771 this would trigger an intra_doc_link_resolution_failure warning
when rustdoc is invoked without --document-private-items. Links from private
items to private types are however never actually generated in that case and
thus shouldn't produce a warning. These links are in fact a very useful tool to
document crate internals.

Tests are added for all 4 combinations of public/private items and link
targets. Test 1 is the case mentioned above and fails without this commit. Tests
2 - 4 passed before already but are added nonetheless to prevent regressions.
@bors bors closed this as completed in c8b16cd Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-intra-doc-links Area: Intra-doc links, the ability to link to items in docs by name C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants