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

Use strip_{prefix,suffix} in rustdoc #74094

Closed
wants to merge 1 commit into from

Conversation

tesuji
Copy link
Contributor

@tesuji tesuji commented Jul 6, 2020

cc @Mark-Simulacrum @jyn514 for rustdoc part

Part of #74048

@rust-highfive
Copy link
Collaborator

r? @GuillaumeGomez

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 6, 2020
// 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'*',
Copy link
Member

@GuillaumeGomez GuillaumeGomez Jul 6, 2020

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

TIL. :)

@GuillaumeGomez
Copy link
Member

Also, what case is it fixing? Because if it's fixing anything, please add a test. :)

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a 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)
Copy link
Member

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.
Copy link
Contributor Author

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.

Copy link
Member

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)
Copy link
Contributor Author

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?

  • /// ...
  • //! ..
  • /** ... */
  • /*! ... */
  • /**
  • /*!

Copy link
Contributor Author

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'*',
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comment on lines -135 to +142
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("*/"))
Copy link
Contributor Author

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);
Copy link
Contributor Author

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.
Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -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();
Copy link
Contributor Author

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.

Comment on lines 814 to 815
// 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());
Copy link
Contributor Author

@tesuji tesuji Jul 6, 2020

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

Copy link
Member

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 "\").

Copy link
Contributor Author

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?

Copy link
Member

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('!')
Copy link
Contributor Author

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 a macro@ prefix,
    e.g. [macro@foo]

I don't know if multiple ! is allowed in that RFC. cc @Manishearth

Copy link
Member

Choose a reason for hiding this comment

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

Only a single one

@tesuji
Copy link
Contributor Author

tesuji commented Jul 6, 2020

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("\\")) {
Copy link
Member

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!

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Jul 6, 2020

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).

@tesuji
Copy link
Contributor Author

tesuji commented Jul 6, 2020

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.
The second case is needed if we want to use str::strip_* methods and leverage its usefulness.

@Mark-Simulacrum
Copy link
Member

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.

@Manishearth
Copy link
Member

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)

@bors
Copy link
Contributor

bors commented Jul 7, 2020

☔ The latest upstream changes (presumably #74117) made this pull request unmergeable. Please resolve the merge conflicts.

@Muirrum Muirrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 24, 2020
@Muirrum
Copy link
Member

Muirrum commented Jul 24, 2020

@lzutao This is a triage bump

@tesuji
Copy link
Contributor Author

tesuji commented Jul 24, 2020

This is blocked on other PR. Closing for now!

@tesuji tesuji closed this Jul 24, 2020
@tesuji tesuji deleted the strip-rustdoc branch June 8, 2024 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants