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: Strip broken links in summaries #79781

Closed
wants to merge 1 commit into from

Conversation

camelid
Copy link
Member

@camelid camelid commented Dec 7, 2020

The primary reason to do this is because intra-doc links are treated as
"broken" in the summary since the resolution context is not available.
Previously, search results with intra-doc links would look like:

This method returns an [Ordering]

but now they look like:

This method returns an Ordering

as search results with regular links do.

The one drawback I can see is if people are using [ and ] literally,
but I think that case is much rarer than using intra-doc links, and they
can and should escape the brackets with a backslash or use inline code.
Plus, this is just for summaries.

r? @jyn514

@camelid camelid added A-markdown-parsing Area: Markdown parsing for doc-comments A-rustdoc-search Area: Rustdoc's search feature C-enhancement Category: An issue proposing an enhancement or a PR with one. S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Dec 7, 2020
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 7, 2020
@camelid
Copy link
Member Author

camelid commented Dec 7, 2020

Before

image

After

image

@camelid
Copy link
Member Author

camelid commented Dec 7, 2020

Before

image

After

image

@jyn514 jyn514 added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Dec 7, 2020
src/librustdoc/html/markdown.rs Show resolved Hide resolved
// NOTE: Make sure to update the same variable in `plain_text_summary`
// if/when you update this one. They have to be duplicated because of a typesystem thing.
let mut broken_link_callback =
|broken_link: BrokenLink<'_>| Some(("#".into(), broken_link.reference.to_owned().into()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This treats every broken link as valid, right? Can we instead use the same logic as for intra-doc links and only replace it if it was resolved?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well we could, but we’d have to thread the intra-doc link information through somehow. If you would like me to do that, could you give me some instructions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This info is available from item.attrs.links: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/struct.Attributes.html#structfield.links. It looks like that's not currently threaded through to short_markdown_summary, but everywhere that calls summary calls it on an Item. I'd suggest making this a method on Item instead and calling item.short_markdown_summary() instead, which gives you access to all the info on the item.

See

// Replace intra-doc links and remove disambiguators from shortcut links (`[fn@f]`).
for an example of actually using the link - I don't expect this to be as complicated since it's just stripping the link altogether, and only for [] style links.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, will I then I have to duplicate broken_link_callback as a closure after all?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why? You're stripping the links in both cases, right?

Copy link
Member Author

@camelid camelid Feb 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been a while since we last discussed this. It looks like the last thing we talked about is letting their be a little duplication and moving the summary functions to be on Item?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's coming back to me now: The reason I temporarily abandoned this is because I was having trouble with the lifetimes of the callback for the summary functions not on Item. I think it might have been the dreaded higher-ranked subtype error. I'll post the error if/when I get it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I tried this type signature:

fn markdown_summary_with_limit(
    md: &str,
    length_limit: usize,
    broken_link_callback: Option<F>,
) -> (String, bool)
where
    F: for<'a> FnMut(BrokenLink<'_>) -> Option<(CowStr<'a>, CowStr<'a>)>,
{ /* ... */ }

but that gives a bunch of errors like:

error[E0582]: binding for associated type `Output` references lifetime `'a`, which does not appear in the trait input types
    --> src/librustdoc/html/markdown.rs:1030:41
     |
1030 |     F: for<'a> FnMut(BrokenLink<'_>) -> Option<(CowStr<'a>, CowStr<'a>)>,
     |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What are the correct lifetimes? I feel like this needs higher-ranked lifetimes (which I added) but as you can see it doesn't work. I need to communicate to the compiler that the return type lifetimes are totally unrelated from the input lifetimes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jyn514 friendly ping :)

If you need to focus on other stuff, don't worry about looking at this now, but you seemed eager to get this working.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try F: FnMut(BrokenLink<'_>) -> Option<(CowStr<'static>, CowStr<'static>)>. That has the same meaning without introducing a new lifetime.

@jyn514
Copy link
Member

jyn514 commented Dec 7, 2020

Also, please add a test for this.

@camelid
Copy link
Member Author

camelid commented Dec 26, 2020

Hmm, why did I mark this PR as blocked?

@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 30, 2020
@jyn514
Copy link
Member

jyn514 commented Feb 15, 2021

@camelid friendly ping :) I think this would be a nice feature to have, happy to help out if you need it.

@camelid
Copy link
Member Author

camelid commented Feb 15, 2021

Yeah, I've been trying to catch up on my S-waiting-on-author PRs. This one is on my list :)

The primary reason to do this is because intra-doc links are treated as
"broken" in the summary since the resolution context is not available.
Previously, search results with intra-doc links would look like:

> This method returns an \[`Ordering`\]

but now they look like:

> This method returns an `Ordering`

as search results with regular links do.

The one drawback I can see is if people are using `[` and `]` literally,
but I think that case is much rarer than using intra-doc links, and they
can and should escape the brackets with a backslash or use inline code.
Plus, this is just for summaries.
@camelid
Copy link
Member Author

camelid commented Feb 16, 2021

Starting with a rebase.

@camelid
Copy link
Member Author

camelid commented Feb 16, 2021

Oops, looks like my rebase included some changes... oh well 😅

@camelid
Copy link
Member Author

camelid commented Feb 16, 2021

Weird, I used git range-diff master @{u} HEAD and it showed no changes:

1:  d32c80467db ! 1:  6c9a5805b0c rustdoc: Strip broken links in summaries
    @@ Commit message
      ## src/librustdoc/html/markdown.rs ##
     @@ src/librustdoc/html/markdown.rs: fn push(s: &mut String, text_length: &mut usize, text: &str) {
              *text_length += text.len();
    -     };
    +     }
      
     -    'outer: for event in Parser::new_ext(md, summary_opts()) {
     +    // NOTE: Make sure to update the same variable in `plain_text_summary`
2:  3f685a724e9 < -:  ----------- Deduplicate broken-link callback

@camelid camelid added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 16, 2021
@jyn514
Copy link
Member

jyn514 commented Feb 23, 2021

I think this is waiting on #79781 (comment). If I'm wrong, feel free to ping me for a review :)

@rustbot label: -S-waiting-on-review +S-waiting-on-author

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 23, 2021
@camelid
Copy link
Member Author

camelid commented Feb 24, 2021

This is blocked on getting a new pulldown-cmark release that includes your lifetimes fix. @rustbot label: -S-waiting-on-author +S-blocked

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 24, 2021
@rustbot rustbot added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Feb 24, 2021
@camelid camelid added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Mar 12, 2021
@camelid camelid added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels May 28, 2021
@jyn514
Copy link
Member

jyn514 commented Jul 2, 2021

@camelid can you test this with a git dependency to make sure that actually fixes it? It seems silly to wait all this time if it doesn't actually affect the error.

@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jul 2, 2021
@camelid
Copy link
Member Author

camelid commented Aug 9, 2021

Actually, it looks like this was fixed in the meantime by #86451! (Although that's only for HTML summaries; plain text summaries that are used for alt-text have not yet been fixed.) I'll close this then.

@camelid camelid closed this Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-markdown-parsing Area: Markdown parsing for doc-comments A-rustdoc-search Area: Rustdoc's search feature C-enhancement Category: An issue proposing an enhancement or a PR with one. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants