Skip to content

intra-doc links: crate::ptr on a re-export of core::slice is not resolved in alloc #76106

New issue
New issue
Closed
Closed
intra-doc links: crate::ptr on a re-export of core::slice is not resolved in alloc#76106
Labels
A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crateA-intra-doc-linksArea: Intra-doc links, the ability to link to items in docs by nameC-bugCategory: This is a bug.E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

Description

@jyn514
jyn514
opened on Aug 30, 2020

It's something to do specifically with the re-export because using ptr instead of crate::ptr works, possibly because it's available in both alloc::slice and core::slice.

I don't understand why this is failing :/ the error is being returned directly from rustc_resolve:

$ RUSTDOC_LOG=rustdoc::passes::collect=debug,rustc_resolve=debug xpy test --stage 1 linkchecker library/alloc
: Some(NodeId(101625)), has_generic_args: false }], opt_ns=Some(MacroNS), record_used=true, path_span=library/alloc/src/lib.rs:1:1: 1:1 (#0), crate_lint=No)
2020-08-29T22:46:53.052491Z DEBUG rustc_resolve: resolve_path ident 0 crate#0 Some(NodeId(101624))
2020-08-29T22:46:53.052494Z DEBUG rustc_resolve: resolve_crate_root(crate#0)
2020-08-29T22:46:53.052496Z DEBUG rustc_resolve: resolve_crate_root: not DollarCrate
2020-08-29T22:46:53.052499Z DEBUG rustc_resolve: resolve_crate_root(crate#0): found no mark (ident.span = library/alloc/src/lib.rs:1:1: 1:1 (#0))
2020-08-29T22:46:53.052502Z DEBUG rustc_resolve: resolve_path ident 1 ptr#0 Some(NodeId(101625))
2020-08-29T22:46:53.053654Z DEBUG rustc_resolve: resolve_path(path=[Segment { ident: crate#0, id: Some(NodeId(101626)), has_generic_args: false }, Segment { ident: ptr#0, id
: Some(NodeId(101627)), has_generic_args: false }], opt_ns=Some(TypeNS), record_used=true, path_span=library/alloc/src/lib.rs:1:1: 1:1 (#0), crate_lint=No)
2020-08-29T22:46:53.053666Z DEBUG rustc_resolve: resolve_path ident 0 crate#0 Some(NodeId(101626))
2020-08-29T22:46:53.053669Z DEBUG rustc_resolve: resolve_crate_root(crate#0)
2020-08-29T22:46:53.053671Z DEBUG rustc_resolve: resolve_crate_root: not DollarCrate
2020-08-29T22:46:53.053673Z DEBUG rustc_resolve: resolve_crate_root(crate#0): found no mark (ident.span = library/alloc/src/lib.rs:1:1: 1:1 (#0))
2020-08-29T22:46:53.053677Z DEBUG rustc_resolve: resolve_path ident 1 ptr#0 Some(NodeId(101627))
2020-08-29T22:46:53.054499Z DEBUG rustdoc::passes::collect_intra_doc_links: crate::ptr resolved to Err(()) in namespace TypeNS with parent DefId(1:6606 ~ core[c85e]::slice[0
])
2020-08-29T22:46:53.055390Z  INFO rustdoc::passes::collect_intra_doc_links: ignoring warning from parent crate: unresolved link to `crate::ptr`

In fact if you look at the debug logging it says itself that it's looking at core: parent DefId(1:6606 ~ core[c85e]::slice[0]). Not sure what's going wrong.

It would be great to find an MCVE of this.

Originally posted by @jyn514 in #75932 (comment)

Activity

  1. Imagejyn514
    added
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    A-intra-doc-linksArea: Intra-doc links, the ability to link to items in docs by name
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    on Aug 30, 2020

  2. jyn514 commented on Aug 30, 2020

    @jyn514
    jyn514
    on Aug 30, 2020
    MemberAuthor

    Direct link to the failing intra-doc link: 6aae4a2#diff-e5a4dbd27d5eadb7a3cf746c396f5420R6430

  3. Imagejyn514
    added
    A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crate
    on Aug 30, 2020

  4. jyn514 commented on Sep 2, 2020

    @jyn514
    jyn514
    on Sep 2, 2020
    MemberAuthor

    Some more test cases from #76235:

    std/sync/struct.Arc.html:214: broken link - std/sync/mem::MaybeUninit::method.assume_init
std/sync/struct.Arc.html:238: broken link - std/sync/mem::MaybeUninit::method.assume_init
alloc/sync/struct.Arc.html:214: broken link - alloc/sync/mem::MaybeUninit::method.assume_init
alloc/sync/struct.Arc.html:238: broken link - alloc/sync/mem::MaybeUninit::method.assume_init
thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:67:9
  5. Imagejyn514
    added a commit that references this issue on Sep 2, 2020

    Revert change to MaybeUninit until rustdoc bugs are fixed

    44bacc3
  6. Imagebors
    closed this as completedin 44bacc3on Sep 3, 2020

  7. jyn514 commented on Sep 3, 2020

    @jyn514
    jyn514
    on Sep 3, 2020
    MemberAuthor

    GitHub was overeager, this is not fixed, just worked around.

  8. Imagejyn514
    reopened this on Sep 3, 2020
  9. Imagedylni
    added a commit that references this issue on Sep 25, 2020

    Fix broken link

    d651dcf

  10. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    @jyn514 I had this issue when documenting quit. It might be easier to test with that crate, since it's small and not part of libstd, but the issue is a little different. crate::with_code works, but with_code is unresolved.

    Rustdoc gives no warnings with either.

  11. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    @dylni that's a separate issue - with_code is additional documentation on the re-export that gets resolved in the scope of the original module instead of in the scope of the re-export. This issue is about documentation that was present to begin with and mysteriously breaks.

  12. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    The fact that it works with crate:: is really odd though. Sounds like something weird is going on with proc-macros, can you open a new issue?

  13. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    Also, I'm starting to think we should revert #56922, it's causing more trouble than it's worth.

  14. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    Sure: #77193

  15. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    Also, I'm starting to think we should revert #56922, it's causing more trouble than it's worth.

    That explains why there aren't any warnings. I agree it might be better to revert that fix. If I'm running with --display-warnings, I would want to see anything that will show as broken in the documentation.

    P.S. Is it expected that [`[String]`] doesn't cause a warning and doesn't resolve?

  16. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    It's definitely expected that it doesn't resolve: You said 'a link to `[String]`', which gets the backticks stripped and rustdoc then sees [String], which isn't a valid rust path.

    [] not warning is intentional but possibly not the best decision. The code for that is here:

    rust/src/librustdoc/passes/collect_intra_doc_links.rs

    Lines 931 to 933 in 78a0894

    if path_str.contains(|ch: char| !(ch.is_alphanumeric() || ch == ':' || ch == '_')) {
    return;
    }

  17. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    rustdoc then sees [String], which isn't a valid rust path.

    My intention was to link to the slice primitive (i.e., &[String]). I know now that intra-rustdoc links don't work on types that include their generic parameters, but it might be an easy thing to miss without the warning. Should I create an issue/PR for adding a warning there?

    Also, sorry for hijacking this issue.

  18. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    Sure, go ahead and open an issue for that too.

    Do you mind joining the discord so we can talk about this more without hijacking the issue further? https://discord.gg/4yEYPuT

  19. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    Discord is refusing to load messages :(

  20. jyn514 commented on Sep 25, 2020

    @jyn514
    jyn514
    on Sep 25, 2020
    MemberAuthor

    Closing as duplicate of #76106, which has more discussion.

  21. Imagejyn514
    closed this as completedon Sep 25, 2020

  22. dylni commented on Sep 25, 2020

    @dylni
    dylni
    on Sep 25, 2020
    Contributor

    @jyn514 I think you meant #77193. ;)

  23. camelid commented on Oct 12, 2020

    @camelid
    camelid
    on Oct 12, 2020
    Member

    I know now that intra-rustdoc links don't work on types that include their generic parameters

    They do now! #76934 :)

  24. dylni commented on Oct 12, 2020

    @dylni
    dylni
    on Oct 12, 2020
    Contributor

    @camelid

    They do now! #76934 :)

    Thanks! Unfortunately, [u8] is still unresolved, but that doesn't technically use generics. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crateA-intra-doc-linksArea: Intra-doc links, the ability to link to items in docs by nameC-bugCategory: This is a bug.E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions