Skip to content

rustdoc: Remove distinction between "regular" and "collapsed" docs #91072

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.

Sign up for GitHub

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

Closed
wants to merge 5 commits into from
Closed

rustdoc: Remove distinction between "regular" and "collapsed" docs #91072

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7be69ba
rustdoc: Make `doc_value()` dispatch to `collapsed_doc_value()`
camelid Nov 20, 2021
da26b51
Remove `doc_value()` and strip `collapsed_` prefix
camelid Nov 20, 2021
22dc5c4
rustdoc: Remove `{Crate,SharedContext}.collapsed`
camelid Nov 20, 2021
8be135b
Write code directly instead of using FromIterator
camelid Nov 20, 2021
1891548
Remove outdated comment
camelid Nov 20, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 1 addition & 12 deletions src/librustdoc/clean/types.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1077,18 +1077,7 @@ impl Attributes {
/// Finds the `doc` attribute as a NameValue and returns the corresponding
/// value found.
crate fn doc_value(&self) -> Option<String> {
let mut iter = self.doc_strings.iter();

let ori = iter.next()?;
let mut out = String::new();
add_doc_fragment(&mut out, ori);
for new_frag in iter {
if new_frag.kind != ori.kind || new_frag.parent_module != ori.parent_module {
break;
}
add_doc_fragment(&mut out, new_frag);
}
if out.is_empty() { None } else { Some(out) }
self.collapsed_doc_value()
Copy link
Member

Choose a reason for hiding this comment

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

This is not the same behavior. The FromIterator impl below is missing the new_frag.kind != ori.kind || new_frag.parent_module != ori.parent_module check.

I'm not sure if it matters in practice, but it seems like something we should have tests for ... could you try and find one or two, or add a new one if not?

Copy link
Member Author

Choose a reason for hiding this comment

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

Before merging collapsed and un-collapsed, I tried removing one part of this conditional and all the tests passed. I'll try removing the whole conditional too (with no other changes) to see what happens.

I agree it'd be good to have more test coverage. I'll see if I can come up with some test cases.

Copy link
Member Author

Choose a reason for hiding this comment

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

All tests pass with master + this diff:

diff --git a/src/librustdoc/clean/types.rs b/src/librustdoc/clean/types.rs
index 41ebf270ba6..5a02a6c6259 100644
--- a/src/librustdoc/clean/types.rs
+++ b/src/librustdoc/clean/types.rs
@@ -1083,9 +1083,6 @@ fn update_need_backline(doc_strings: &mut Vec<DocFragment>) {
         let mut out = String::new();
         add_doc_fragment(&mut out, ori);
         for new_frag in iter {
-            if new_frag.kind != ori.kind || new_frag.parent_module != ori.parent_module {
-                break;
-            }
             add_doc_fragment(&mut out, new_frag);
         }
         if out.is_empty() { None } else { Some(out) }

So either that conditional is useless or we don't have any test coverage for 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.

Adding enough test coverage around this code to know for sure that nothing is changing will take a long time. What about if I open a PR to remove this conditional, we land it, and wait to see if any regressions pop up? If there are any regressions, then we can do a quick revert since it's just a few lines. If we don't find any regressions, then we can move forward with a bigger change.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, I'm ok with that, but let's wait until after the beta branch on friday.

Copy link
Member Author

Choose a reason for hiding this comment

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

Opened #91305.

}

/// Return the doc-comments on this item, grouped by the module they came from.
Expand Down