rustdoc: simplify highlight.rs
Split render_with_highlighting, which took many optional parameters, into three functions for specific purposes, which each take a smaller number of mostly required parameters.
Remove some plumbing to pass through an "edition" parameter, which was used solely to avoid highlighting some 2021 Edition keywords in non-2021 code.
I've tested a build of std docs before and after, and this does not change the generated HTML at all.
Followup from https://github.com/rust-lang/rust/pull/91264#discussion_r901151101
r? ```@GuillaumeGomez```
Split render_with_highlighting, which took many optional parameters, into three
functions for specific purposes, which each take a smaller number of mostly
required parameters.
Remove some plumbing to pass through an "edition" parameter, which was used
solely to avoid highlighting some 2021 Edition keywords in non-2021 code.
Use modern formatting for format! macros
This updates the standard library's documentation to use the new format_args syntax.
The documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
`eprintln!("{}", e)` becomes `eprintln!("{e}")`, but `eprintln!("{}", e.kind())` remains untouched.
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.
A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
Fix table in docblocks
"Overwrite" of #88702.
Instead of adding a z-index to the sidebar (which only hides the issue, doesn't fix it), I wrap `<table>` elements inside a `<div>` and limit all chidren of `.docblock` elements' width to prevent having the scrollbar on the whole doc block.
Thanks `@nbdd0121` for `overflow-x: auto;`. ;)
r? `@notriddle`
`rustdoc`: compute correct line number for indented rust code blocks.
This PR fixes a bug in `rustdoc` where it computes the wrong line number for indented rust code blocks (and subsequent blocks) it finds in markdown strings. To fix this issue, we decrement the line number if we find characters between the code block and the preceding line ending. I noticed this issue as I was trying to use `rustdoc` to extract examples from The Rust Reference and run them through the [Rust Model Checker](https://github.com/model-checking/rmc).
It was accidentally changed to use `opts()` in #86451.
I also renamed `opts()` to `main_body_opts()` to make this kind of
accidental change less likely.
Refactor Markdown length-limited summary implementation
This PR is a new approach to #79749.
This PR refactors the implementation of `markdown_summary_with_limit()`,
separating the logic of determining when the limit has been reached from
the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
r? `@GuillaumeGomez`
This commit refactors the implementation of
`markdown_summary_with_limit()`, separating the logic of determining
when the limit has been reached from the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
