-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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: Return a String from collapsed_doc_value, not an Option #92078
Conversation
rustdoc-json-types is a public (although nightly-only) API. Consider changing cc @CraftSpider,@aDotInTheVoid Some changes occurred in cc @camelid |
d418cfe
to
c7476ad
Compare
cc @GuillaumeGomez since you said in #91072 (comment) you thought the distinction was useful, although I'm not quite sure why ... IMO the new explicit checks are more clear. |
rustdoc: Write doc-comments directly instead of using FromIterator The FromIterator impl made the code much harder to understand. The types don't make sense until you realize there's a custom FromIterator impl. This is the first commit from rust-lang#91305; since `@camelid` wrote it originally I don't feel bad unilaterally approving it. r? `@ghost` `@bors` r+ Note that this will conflict with rust-lang#92078.
It's because of how the code is written: you can forget to check that a string is new but you can't forget to check if an |
@GuillaumeGomez right, but often you don't need to check if it's empty or not. I encourage you to look at the diff: very few places actually keep the check and those that do only keep it as a small optimization. |
I agree with you on that but the problem is not more the majority but for the minority. It's not a hard blocker for me, but still something that needs to be considered. I relied on the compiler to avoid that whereas you rely on the developer. It's a paradigm shift. |
@GuillaumeGomez if it helps, another motivation for this was making |
Leet's just say I'm not convinced but you seem to be sure so like I said: I'll remain neutral. |
if let Some(doc) = attrs.collapsed_doc_value() { | ||
// `doc_value()` doesn't combine sugared/raw doc attributes, this will combine them for us. | ||
let docs = attrs.collapsed_doc_value(); | ||
if !docs.is_empty() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure this slight behavior change here and elsewhere doesn't matter? Before, this checked for if there were no DocFragments; now, it checks if the collapsed docs is an empty string.
I think it's probably "more correct" now, but I just wanted to double-check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at https://github.com/rust-lang/rust/blob/c7476adc38bc9348398afcf24117d7d48e7ba9f1/src/librustdoc/html/markdown.rs#L732, it doesn't do anything for empty strings any way; having a check here at all is a microoptimization we could probably remove. So the change shouldn't have an impact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this code is looking for doctests, not rendering Markdown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there should be a behavior change, but there is a very slight possibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This if
calls find_testable_code
immediately below. The parser there is parsing the code for doctests.
rustdoc: Write doc-comments directly instead of using FromIterator The FromIterator impl made the code much harder to understand. The types don't make sense until you realize there's a custom FromIterator impl. This is the first commit from rust-lang#91305; since ``@camelid`` wrote it originally I don't feel bad unilaterally approving it. r? ``@ghost`` ``@bors`` r+ Note that this will conflict with rust-lang#92078.
This comment has been minimized.
This comment has been minimized.
/// The full markdown docstring of this item. Absent if there is no documentation at all, | ||
/// Some("") if there is some documentation but it is empty (EG `#[doc = ""]`). | ||
pub docs: Option<String>, | ||
/// The full markdown docstring of this item. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only change in behavior is that the JSON backend no longer distinguishes
"undocumented" and "documented with the empty string". This doesn't seem like a particularly useful distinction,
but I can add it back for that code only if you think it's important.
This change seems good to me, but I think this sould be added to the docs
field documentation.
Also their should probably be a test for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing, done :)
This has almost no effect in practice, since most places were using `unwrap_or_default`, and the rest were doing checks that *should* have been checking for an empty string. The only change in behavior is that the JSON backend no longer distinguishes "undocumented" and "documented with the empty string". This doesn't seem like a particularly useful distinction, but I can add it back for that code only if you think it's important.
3677299
to
026b1b3
Compare
This comment has been minimized.
This comment has been minimized.
026b1b3
to
2ef6ae2
Compare
This comment has been minimized.
This comment has been minimized.
This also fixes a few bugs in jsondocck and makes some of its errors easier to read.
2ef6ae2
to
112ed0b
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #92095) made this pull request unmergeable. Please resolve the merge conflicts. |
ditto #92079 (comment) |
This has almost no effect in practice, since most places were using
unwrap_or_default
,and the rest were doing checks that should have been checking for an empty string.
The only change in behavior is that the JSON backend no longer distinguishes
"undocumented" and "documented with the empty string". This doesn't seem like a particularly useful distinction,
but I can add it back for that code only if you think it's important.
Builds on #92077. cc #91072 (comment)
cc @CraftSpider @HeroicKatora
r? @camelid