-
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
Rollup of 6 pull requests #101805
Rollup of 6 pull requests #101805
Conversation
At the time this CSS was added, it was just `span.since`, because the version info could be rendered in two different ways: 1. `<div class='since'>` was used for associated items like methods. It was absolutely positioned, and the selector in rustdoc.css that targetted it was just `.since`. https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L522-L529 2. `<span class='since'>` was introduced in a5a2f2b for page-global version info, so that it could be laid out alongside the `[-]`/`[+]` button. This CSS rule was added to override the absolute position introduced in (1). https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L637-L641 The selector was changed in 8fc6e42 so that everything could use a `<span>` tag, but the dichotomy of the absolutely-positioned version info for associated items and the static positioned item version info remained. The absolutely positioned `.since` was changed to one nested below a `<div class="rightside">` container in 5de1391, so the version information is now always statically-positioned, and, as described in the commit message, "their DOM representation is consistent."
The `.content table` / `.content td` / `.content tr` family of selectors date back to 4fd061c, when module indexes and other parts of rustdoc used `<table>` tags for layout and content presentation. The `.content td h1, .content td h2` has only been changed since then to tweak the font size in dd5ff42. https://github.com/rust-lang/rust/blob/4fd061c426902b0904c65e64a3780b21f9ab3afb/src/rustdoc_ng/html/static/main.css#L155-L162 This CSS would have affected: * search result tables, which were removed in b615c0c * module item tables, which were removed in 6020c79 * docblock tables from markdown, which still exist It may also have affected a few other tables over the last decade, but they've been gradually replaced with grid layouts and flexbox to make layouts that work better on narrow viewports. For example, 34bd2b8. These rules have no affect on the appearance of docblock tables =============================================================== .content table { border-spacing: 0 5px; } According to MDN, [border-spacing] only has an effect when `border-collapse` is `separate`. However, `border-collapse: collapse` is set globally for all tables, so this rule does nothing. [border-spacing]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-spacing .content td p:first-child { margin-top: 0; } Tables with paragraphs in them are impossible without dropping down to raw HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin anyway, so this rule is a no-op. .content td h1, .content td h2 { margin-left: 0; font-size: 1.125rem; } Tables with headers in them are impossible without dropping down to raw HTML. This is considered unlikely, especially since it looks weird right now (`.docblock h2` has an underline that is redundant with the table cell's own border). .content tr:first-child td { border-top: 0; } This has no effect because of border collapsing. This rule is removed, because tables look fine without it ========================================================= .content td:first-child { padding-right: 20px; } By removing this rule, the first cell in each row has the same padding as all other cells in the row. This rule is kept, and converted to directly target `.docblock` =============================================================== .content td { vertical-align: top; } Removing this rule would cause it to be aligned to the middle instead.
…-error, r=compiler-errors Emit a note that static bounds from HRTBs are a bug This note isn't perfect, but opening this to either 1) land as is or 2) get some feedback on how to improve it Let r? `@compiler-errors` and cc. `@nikomatsakis`
smol grammar changes to README.md smol grammar changes to README.md
…an-since, r=GuillaumeGomez rustdoc: remove redundant CSS `.out-of-band > span.since { position }` At the time this CSS was added, it was just `span.since`, because the version info could be rendered in two different ways: 1. `<div class='since'>` was used for associated items like methods. It was absolutely positioned, and the selector in rustdoc.css that targetted it was just `.since`. https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L522-L529 2. `<span class='since'>` was introduced in a5a2f2b for page-global version info, so that it could be laid out alongside the `[-]`/`[+]` button. This CSS rule was added to override the absolute position introduced in (1). https://github.com/rust-lang/rust/blob/a5a2f2b951ea982a666eaf52b1874d8f1b17290b/src/librustdoc/html/static/rustdoc.css#L637-L641 The selector was changed in 8fc6e42 so that everything could use a `<span>` tag, but the dichotomy of the absolutely-positioned version info for associated items and the static positioned item version info remained. The absolutely positioned `.since` was changed to one nested below a `<div class="rightside">` container in 5de1391, so the version information is now always statically-positioned, and, as described in the commit message, "their DOM representation is consistent."
…ics, r=jackh726 Also replace the placeholder for the stable_features lint Follow up of rust-lang#101215 and rust-lang#100591 . Fixes rust-lang#101766
… r=GuillaumeGomez rustdoc: remove outdated CSS `.content table` etc # Screenshot before ![image](https://user-images.githubusercontent.com/1593513/189992665-238aab28-d224-4466-901c-6e35e79182fb.png) # Screenshot after ![image](https://user-images.githubusercontent.com/1593513/189992762-35c8efe4-e980-40bd-b72c-3ae4cfd6f830.png) # Description The `.content table` / `.content td` / `.content tr` family of selectors date back to 4fd061c, when module indexes and other parts of rustdoc used `<table>` tags for layout and content presentation. The `.content td h1, .content td h2` has only been changed since then to tweak the font size in dd5ff42. https://github.com/rust-lang/rust/blob/4fd061c426902b0904c65e64a3780b21f9ab3afb/src/rustdoc_ng/html/static/main.css#L155-L162 This CSS would have affected: * search result tables, which were removed in b615c0c * module item tables, which were removed in 6020c79 * docblock tables from markdown, which still exist It may also have affected a few other tables over the last decade, but they've been gradually replaced with grid layouts and flexbox to make layouts that work better on narrow viewports. For example, 34bd2b8. These rules have no affect on the appearance of docblock tables --------------------------------------------------------------- .content table { border-spacing: 0 5px; } According to MDN, [border-spacing] only has an effect when `border-collapse` is `separate`. However, `border-collapse: collapse` is set globally for all tables, so this rule does nothing. [border-spacing]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-spacing .content td p:first-child { margin-top: 0; } Tables with paragraphs in them are impossible without dropping down to raw HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin anyway, so this rule is a no-op. .content td h1, .content td h2 { margin-left: 0; font-size: 1.125rem; } Tables with headers in them are impossible without dropping down to raw HTML. This is considered unlikely, especially since it looks weird right now (`.docblock h2` has an underline that is redundant with the table cell's own border). .content tr:first-child td { border-top: 0; } This has no effect because of border collapsing. This rule is removed, because tables look fine without it --------------------------------------------------------- .content td:first-child { padding-right: 20px; } By removing this rule, the first cell in each row has the same padding as all other cells in the row. This rule is kept, and converted to directly target `.docblock` --------------------------------------------------------------- .content td { vertical-align: top; } Removing this rule would cause it to be aligned to the middle instead.
…=jyn514 Update test output for drop tracking rust-lang#97334 has a lot of updates to test outputs that makes the PR larger than it needs to be. This PR pulls those changes out so we can keep the other one as simple as possible. r? `@jyn514`
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: c97922dca5 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (a926696): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
Interesting perf results. The small diesel regression looks real, but the large wg-grammar improvement also looks real. And if you look at cycles there are improvements to wg-grammar, tt-muncher, and deep-vector, all of which are benchmarks that chew through large amounts of repetitive code. Which suggests some kind of improvement to AST traversal or something like that. # #101433 seems the most likely cause: @rust-timer build b512bbede20f6f1ec7a77e2a226dbc38578f118a |
Queued b512bbede20f6f1ec7a77e2a226dbc38578f118a with parent c97922d, future comparison URL. |
Finished benchmarking commit (b512bbede20f6f1ec7a77e2a226dbc38578f118a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
That confirms #101433 is responsible for the perf effects of this rollup. |
Moving the perf regression label to #101433. |
Successful merges:
.out-of-band > span.since { position }
#101769 (rustdoc: remove redundant CSS.out-of-band > span.since { position }
).content table
etc #101773 (rustdoc: remove outdated CSS.content table
etc)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup