-
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
Use strip_{prefix,suffix}
in rustdoc
#74094
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
// starts with `/**` and ends with `*/`. However, this caused an ICE | ||
// because some code assumed that the length of a doc comment is at least 5. | ||
let yes = match s.as_bytes() { | ||
[b'/', b'*', b'*', c, _, ..] => *c != b'*', |
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'm surprised that we still allow /**
to be a doc comment. Is it something allowed officially? I never saw it anywhere.
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.
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.
TIL. :)
Also, what case is it fixing? Because if it's fixing anything, please add a test. :) |
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 am concerned that it seems like at least some of my comments from the previous PR have not been addressed. I would prefer not to have to review again or try to copy my comments over myself...
|| (s.starts_with("/**") && is_block_doc_comment(s)) | ||
|| s.starts_with("/*!") | ||
fn is_doc_comment(s: &str) -> bool { | ||
is_line_doc_comment(s) || is_block_doc_comment(s) |
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 left a review on the previous PR here - this is a change in behavior due to checking the length for e.g. /*!
. I would ask that any changes in behavior are at least split into their own commit in this PR and as such clearly identifiable, ideally, they would be made in a separate PR. This one for example seems to have backwards compatibility concerns.
} | ||
|
||
// FIXME(#64197): Try to privatize this again. |
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.
cc https://github.com/rust-lang/rust/pull/74048/files#r449877369
I made it private now by using is_line_doc_comment
in test.
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 continue to prefer that we not conflate the move to using strip_{prefix,suffix} with other changes, just because it makes it harder to review and increases the chances of missing something. At the very least combining them in the same commit is quite frustrating for things like git blame later on.
|| (s.starts_with("/**") && is_block_doc_comment(s)) | ||
|| s.starts_with("/*!") | ||
fn is_doc_comment(s: &str) -> bool { | ||
is_line_doc_comment(s) || is_block_doc_comment(s) |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449877504
It is not clear to me what is the input of is_doc_comment
?
Does it like the followings?
/// ...
//! ..
/** ... */
/*! ... */
/**
/*!
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.
Also there are no testcases cover this function?
// starts with `/**` and ends with `*/`. However, this caused an ICE | ||
// because some code assumed that the length of a doc comment is at least 5. | ||
let yes = match s.as_bytes() { | ||
[b'/', b'*', b'*', c, _, ..] => *c != b'*', |
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 comment.starts_with("/*") { | ||
let lines = | ||
comment[3..comment.len() - 2].lines().map(|s| s.to_string()).collect::<Vec<String>>(); | ||
match comment | ||
.strip_prefix("/**") | ||
.or_else(|| comment.strip_prefix("/*!")) | ||
.and_then(|s| s.strip_suffix("*/")) |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449877722
I am quite sure that with block doc comment must start with either /**
or /*!
and must end with */
as the reference states: https://doc.rust-lang.org/nightly/reference/comments.html#doc-comments
}; | ||
// SAFETY: `new_len` should be in between char boundary | ||
unsafe { | ||
s.as_mut_vec().set_len(new_len); |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449880719
String::truncate
is cheap but there is panicking branch not elided: https://rust.godbolt.org/z/VTZ3Le
Also miri confirms that this is safe.
// have no easy way of removing a potential single space after the hashes, which | ||
// is done in the single # case. This inconsistency seems okay, if non-ideal. In | ||
// order to fix it we'd have to iterate to find the first non-# character, and | ||
// then reallocate to remove it; which would make us return a String. |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449881015
I have no idea what this comment is talking about.
Does it replace "##" with "#" as the old code did?
So should I keep the old FIXME?
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.
Oh you wrote this code: ffe12b1 and has a test here: https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/issue-41783.rs
@@ -776,10 +775,10 @@ impl LangString { | |||
data.no_run = true; | |||
} | |||
x if x.starts_with("edition") => { | |||
data.edition = x[7..].parse::<Edition>().ok(); | |||
data.edition = x.strip_prefix("edition").unwrap().parse::<Edition>().ok(); |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449881344
I changed the code to use strip_prefix
to avoid panicking code caused by slicing.
src/librustdoc/html/render.rs
Outdated
// Ends with "\\" (it's the case for the last added crate line) | ||
ret.push(line[..line.len() - 1].to_string()); | ||
ret.push(head.to_string()); |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449881783
The comment above this statement confirms that the else
case line
ends with \\
.
cc @GuillaumeGomez who wrote this code in b4fb306
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.
Normally, all lines should end with ",\" (except the last one which ends with "\").
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.
So does I reserve old behavior here?
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.
Yes please
link.trim_start_matches("derive@") | ||
} else if link.ends_with('!') { | ||
kind = Some(MacroNS); | ||
link.trim_end_matches('!') |
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.
re https://github.com/rust-lang/rust/pull/74048/files#r449882381
Quoting intra doc link RFC:
- In links to macros,
the link label can end with a!
,
e.g.,Look at the [FOO!] macro
. You can alternatively use amacro@
prefix,
e.g.[macro@foo]
I don't know if multiple !
is allowed in that RFC. cc @Manishearth
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.
Only a single one
I replied to most review comments about rustdoc (#74048). |
// Ends with "\\" (it's the case for the last added crate line) | ||
ret.push(line[..line.len() - 1].to_string()); | ||
// Ends with "\\" (it's the case for the last added crate line) | ||
if let Some(head) = line.strip_suffix(",\\").or_else(|| line.strip_suffix("\\")) { |
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.
Like this seems fine to me, thanks!
I continue to be pretty strongly opposed to making both functional changes, regardless of whether we think they're fine, and "pure cleanup" of using the new functions from std in the same PR. At the very least, I am not confident that my original review caught all such cases -- and without separate commits at least for them, it makes it hard to evaluate whether the breaking changes being made are acceptable or not. I will try to reply to your comments shortly. (Edit: it looks like all of the ones on this PR are trying to justify making unrelated changes, and I'd just prefer that we don't make them at all in this PR). |
Many behavior changes are either:
The first case, most of them I think the intent is really clear as there is an if condition check if str starts/ends with pattern only once. |
I don't disagree that it's likely that the behavior changes are benign, but I am personally against landing a PR that has a bunch of (very minor) breaking changes to various parts of the codebase without any evaluation of what those changes are exactly. I also don't really trust myself to have caught every case where there has been a behavior change, especially when some of those are being made intentionally it seems (so it's not just "accidents" that review needs to catch). I think it's generally a good idea to have a breaking change "set" at least split out into its own PR and then we can evaluate whether the code readability of strip_prefix is worth potentially breaking users, even if we unintentionally were accepting behavior of some kind before. Making that evaluation without a list of the changes being made is quite difficult. |
I agree with @Mark-Simulacrum , we should not mix behavior changes with refactors like this. The changes being benign is already false: you introduced a bug in #74094 (comment) |
☔ The latest upstream changes (presumably #74117) made this pull request unmergeable. Please resolve the merge conflicts. |
@lzutao This is a triage bump |
This is blocked on other PR. Closing for now! |
cc @Mark-Simulacrum @jyn514 for rustdoc part
Part of #74048