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

librustdoc: remove unused for_html field from Buffer 🦄 #136656

Conversation

yotamofek
Copy link
Contributor

So while, err... in the throes of trying to put myself out (😁), I realized that the for_html is never actually read, just initialized.

I'm not sure there's much purpose to Buffer without it, might be worth completely yanking it out? It's quite a bit of boilerplate for, basically, allowing us to avoid a few useless .unwrap()s.

r? @GuillaumeGomez (again, feel free to re-assign)
and also cc @Mark-Simulacrum because git blame shows you originally added the Buffer abstraction, maybe you know what for_html was originally used for?

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Feb 6, 2025
@GuillaumeGomez
Copy link
Member

I think we can get rid of Buffer too.

@yotamofek
Copy link
Contributor Author

Cool! On it.

@yotamofek
Copy link
Contributor Author

yotamofek commented Feb 8, 2025

Superseded by #136748

@yotamofek yotamofek closed this Feb 8, 2025
@yotamofek yotamofek deleted the pr/rustdoc-remove-buffer-for-html branch February 8, 2025 21:10
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 9, 2025
…r=<try>

Nuke `Buffer` abstraction from `librustdoc` 💣

In rust-lang#136656  I found out that the `for_html` field in the `Buffer` struct was never read, and pondered if `Buffer` had any utility at all. `@GuillaumeGomez`  said he agrees that it can be just removed. So this PR is me removing it. So, r? `@GuillaumeGomez`

But...
this got *a lot* bigger than I had planned.
A lot of functions had a `&mut Buffer` arg, but instead of replacing it with a `buf: impl fmt::Write` arg, I decided to change those functions to return an opaque `impl fmt::Display` instead.

If this PR turns out to be contentious I can try to make a PR that just removes the `Buffer` struct and tries to make less invasive changes, but personally I do like some of the cleanups that this PR allows. Let's see what others think! I think it'll be better to review this without whitespace (If this gets positive reactions, I'll need to rebase and maybe try to separate this into logical commits, but not sure if that's very practical)

While most of the PR is "cosmetic", I did make some small changes, mostly trying to make some of the formatting lazier, and do less allocations. So a perf run will be nice :)

### Pros and cons of returning `impl fmt::Display` instead of taking a `impl fmt::Write`

#### Cons:
- Named lifetimes: function signatures got a lot more verbose because the RPIT opaque type needs to be explicitly bound by the lifetimes of the refs in the arguments
- Having to use `fmt::from_fn` causes another level of indentation
- Immutable closures, can't move out of non-`Copy` items (wasn't much of a problem in practice)

#### Pros:
- Less arguments, no un-Rusty "out" argument
- Nicer composability, allows the returned type to be directly used in format strings

### Interchangeability

A function receiving a `impl fmt::Write` can be turned into a function returning a `impl fmt::Display` by using `fmt::from_fn`.
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 9, 2025
…ake2, r=<try>

Nuke `Buffer` abstraction from `librustdoc`, take 2 💣

In rust-lang#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?

Supersedes rust-lang#136748
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Feb 12, 2025
…-take2, r=GuillaumeGomez

Nuke `Buffer` abstraction from `librustdoc`, take 2 💣

In rust-lang#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?

Supersedes rust-lang#136748
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Feb 12, 2025
…-take2, r=GuillaumeGomez

Nuke `Buffer` abstraction from `librustdoc`, take 2 💣

In rust-lang#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?

Supersedes rust-lang#136748
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 12, 2025
Rollup merge of rust-lang#136784 - yotamofek:pr/rustdoc-remove-buffer-take2, r=GuillaumeGomez

Nuke `Buffer` abstraction from `librustdoc`, take 2 💣

In rust-lang#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?

Supersedes rust-lang#136748
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Feb 13, 2025
…=GuillaumeGomez

Nuke `Buffer` abstraction from `librustdoc`, take 2 💣

In rust-lang/rust#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?

Supersedes #136748
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants