rustdoc: use svgo to shrink `wheel.svg`
use [svgo] to shrink `wheel.svg`
[svgo]: https://github.com/svg/svgo
$ du -bs src/librustdoc/html/static/images/wheel.svg wheel-old.svg
2972 src/librustdoc/html/static/images/wheel.svg
3764 wheel-old.svg
100*((2972-3764)/3764) = -21.04%
rustdoc: use a newline instead of `<br>` to format code headers
Since these elements now use `white-space: pre-wrap` since #107615, it's fine to use newlines for formatting, which is smaller and a bit less complicated.
Since these elements now use `white-space: pre-wrap` since
784665d4ce, it's fine to use newlines
for formatting, which is smaller and a bit less complicated.
Replace nbsp in all rustdoc code blocks
Based on #106125 by `@dtolnay` — this PR fixes the line wrapping bug.
Fixes#106098. This makes code copyable from rustdoc rendered documentation into a Rust source file.
Inline CSS background images directly into the CSS
A nice advantage of this is that it removes a few entries in the list of static files.
r? ``@notriddle``
Migrate last part of CSS themes to CSS variables
No changes in the output. This is already tested in `tests/rustdoc-gui/search-tab.goml` so no need to add a GUI test.
r? `@notriddle`
Keep all theme-updating logic together
Prior to this PR, if the page is restored from the browser bfcache¹, we call `switchToSavedTheme`. But `switchToSavedTheme` never looks at the `use-system-theme` preference. Further, if it can't find a saved theme, it will fall back to the default of "light".
For a user with cookies disabled² whose preferred color scheme is dark, this means the theme will wobble back and forth between dark and light. The sequence that occurs is,
1. The page is loaded. During a page load, we consult `use-system-theme`: as cookies are disabled, this preference is unset. The default is true.
Because the default is true, we look at the preferred color scheme: for our example user, that's "dark". **The page theme is set to dark.** We'll attempt to store these preferences in localStorage, but fail due to cookies being disabled.
2. The user navigates through the docs. Subsequent page loads happen, and the same process in step 1 recurs. Previous pages are (potentially) put into the bfcache.
3. The user navigates backwards/forwards, causing a page in bfcache to be pulled out of cache. The `pageShow` event handler is triggered. However, this calls `switchToSavedTheme`: this doesn't consider the system theme, as noted above. Instead, it only looks for a saved theme. However, with cookies disabled, there is none. It defaults to light. **The page theme is set to light!** The user wonders why the dark theme is lost.
There are effectively two functions trying to determine and apply the correct theme: `updateSystemTheme` and `switchToSavedTheme`. Thus, we merge them into just one: `updateTheme`. This function contains all the logic for determining the correct theme, and is called in all circumstances where we need to set the theme:
* The initial page load
* If the browser preferred color scheme (i.e., light/dark mode) is changed
* If the page is restored from bfcache
* If the user updates the theme preferences (i.e., in `settings.js`)
Fixes https://github.com/rust-lang/rust/issues/94250.
¹bfcache: https://web.dev/bfcache/ The bfcache is used to sleep a page, if the user navigates away from it, and to restore it from cache if the user returns to it.
²Note that the browser preference that enables/disables cookies really controls many forms of storage. The same preference thus also affects localStorage. (This is so a normal browser user doesn't need to understand the distinction between "cookies" and "localStorage".)
Prior to this PR, if the page is restored from the browser bfcache¹, we
call `switchToSavedTheme`. But `switchToSavedTheme` never looks at the
`use-system-theme` preference. Further, if it can't find a saved theme,
it will fall back to the default of "light".
For a user with cookies disabled² whose preferred color scheme is dark,
this means the theme will wobble back and forth between dark and light.
The sequence that occurs is,
1. The page is loaded. During a page load, we consult
`use-system-theme`: as cookies are disabled, this preference is
unset. The default is true.
Because the default is true, we look at the preferred color scheme:
for our example user, that's "dark". **The page theme is set to
dark.** We'll attempt to store these preferences in localStorage, but
fail due to cookies being disabled.
2. The user navigates through the docs. Subsequent page loads happen,
and the same process in step 1 recurs. Previous pages are
(potentially) put into the bfcache.
3. The user navigates backwards/forwards, causing a page in bfcache to
be pulled out of cache. The `pageShow` event handler is triggered.
However, this calls `switchToSavedTheme`: this doesn't consider the
system theme, as noted above. Instead, it only looks for a saved
theme. However, with cookies disabled, there is none. It defaults to
light. **The page theme is set to light!** The user wonders why the
dark theme is lost.
There are effectively two functions trying to determine and apply the
correct theme: `updateSystemTheme` and `switchToSavedTheme`. Thus, we
merge them into just one: `updateTheme`. This function contains all the
logic for determining the correct theme, and is called in all
circumstances where we need to set the theme:
* The initial page load
* If the browser preferred color scheme (i.e., light/dark mode) is
changed
* If the page is restored from bfcache
* If the user updates the theme preferences (i.e., in `settings.js`)
Fixes#94250.
¹bfcache: https://web.dev/bfcache/ The bfcache is used to sleep a page,
if the user navigates away from it, and to restore it from cache if the
user returns to it.
²Note that the browser preference that enables/disables cookies really
controls many forms of storage. The same preference thus also affects
localStorage. (This is so a normal browser user doesn't need to
understand the distinction between "cookies" and "localStorage".)
Remove HirId -> LocalDefId map from HIR.
Having this map in HIR prevents the creating of new definitions after HIR has been built.
Thankfully, we do not need it.
Based on https://github.com/rust-lang/rust/pull/103902
Remove `ControlFlow::{BREAK, CONTINUE}`
Libs-API decided to remove these in #102697.
Follow-up to #107023, which removed them from `compiler/`, but a couple new ones showed up since that was merged.
r? libs
Compute generator saved locals on MIR
Generators are currently type-checked by introducing a `witness` type variable, which is unified with a `GeneratorWitness(captured types)` whose purpose is to ensure that the auto traits correctly migrate from the captured types to the `witness` type. This requires computing the captured types on HIR during type-checking, only to re-do it on MIR later.
This PR proposes to drop the HIR-based computation, and only keep the MIR one. This is done in 3 steps.
1. During type-checking, the `witness` type variable is never unified. This allows to stall all the obligations that depend on it until the end of type-checking. Then, the stalled obligations are marked as successful, and saved into the typeck results for later verification.
2. At type-checking writeback, `witness` is replaced by `GeneratorWitnessMIR(def_id, substs)`. From this point on, all trait selection involving `GeneratorWitnessMIR` will fetch the MIR-computed locals, similar to what opaque types do. There is no lifetime to be preserved here: we consider all the lifetimes appearing in this witness type to be higher-ranked.
3. After borrowck, the stashed obligations are verified against the actually computed types, in the `check_generator_obligations` query. If any obligation was wrongly marked as fulfilled in step 1, it should be reported here.
There are still many issues:
- ~I am not too happy having to filter out some locals from the checked bounds, I think this is MIR building that introduces raw pointers polluting the analysis;~ solved by a check specific to static variables.
- the diagnostics for captured types don't show where they are used/dropped;
- I do not attempt to support chalk.
cc `@eholk` `@jyn514` for the drop-tracking work
r? `@oli-obk` as you warned me of potential unsoundness
