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.

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

Jump to bottom

Rustdoc should only end the 1st sentence at a . that is followed by a space. #8617

Closed
orenbenkiki opened this issue Aug 19, 2013 · 3 comments
Closed

Rustdoc should only end the 1st sentence at a . that is followed by a space. #8617

orenbenkiki opened this issue Aug 19, 2013 · 3 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@orenbenkiki
Copy link

For example, if the 1st sentence is "This is the foo library version 1.0 which does good stuff.", rustdoc will incorrectly consider the 1st sentence to be "This is the foo library version 1.".
@huonw
Copy link
Member

huonw commented Aug 19, 2013

(I assume you meant that it should only end when the . is followed by a space; I amended the title to change ... is not followed ... :) )

Part of #8125. (@cmr, @Seldaek, any input?)

@huonw huonw mentioned this issue Aug 19, 2013
Closed
@Seldaek
Copy link
Contributor

Seldaek commented Aug 19, 2013

Right now rustdoc_web (the new docs) makes the cut between short description and the rest of the docblock at the first \n\n. The reason is that many functions have two sentence one-liner descriptions and splitting those really doesn't make sense IMO, but it's an easy fix if it's deemed that splitting at the first sentence boundary is better.

@alexcrichton
Copy link
Member

This is no longer relevant with rustdoc_ng. The detection of \n\n was implemented, and it appears to be working ok.

This can certainly be reopened if it's still a problem.

flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2022
@bors
Auto merge of rust-lang#8617 - Alexendoo:relax-needless-late-init, r=…
95396f6 
…giraffate

`needless_late_init`: ignore `if let`, `let mut` and significant drops

No longer lints `if let`, personal taste on this one is pretty split, so it probably shouldn't be warning by default. Fixes rust-lang#8613

```rust
let x = if let Some(n) = y {
    n
} else {
    1
}
```

No longer lints `let mut`, things like the following are not uncommon and look fine as they are

https://github.com/shepmaster/twox-hash/blob/b169c16d86eb8ea4a296b0acb9d00ca7e3c3005f/src/sixty_four.rs#L88-L93

Avoids changing the drop order in an observable way, where the type of `x` has a drop with side effects and something between `x` and the first use also does, e.g.

https://github.com/denoland/rusty_v8/blob/48cc6cb791cac57d22fab1a2feaa92da8ddc9a68/tests/test_api.rs#L159-L167

The implementation of `type_needs_ordered_drop_inner` was changed a bit, it now uses `Ty::has_significant_drop` and reordered the ifs to check diagnostic name before checking the implicit drop impl

changelog: [`needless_late_init`]: No longer lints `if let` statements, `let mut` bindings and no longer significantly changes drop order
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alexcrichton @orenbenkiki @Seldaek @huonw