-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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 7 pull requests #92580
Rollup of 7 pull requests #92580
Conversation
According to MDN (https://developer.mozilla.org/en-US/docs/Web/CSS/font-size), > To maximize accessibility, it is generally best to use values that > are relative to the user's default font size. > Defining font sizes in px is not accessible, because the user cannot > change the font size in some browsers. Note that changing font size (in browser or OS settings) is distinct from the zoom functionality triggered with Ctrl/Cmd-+. Zoom functionality increases the size of everything on the page, effectively applying a multiplier to all pixel sizes. Font size changes apply to just text. For relative font sizes, we could use `em`, as we do in several places already. However that has a problem of "compounding" (see MDN article for details). The compounding problem is nicely solved by `rem`, which make font sizes relative to the root element, not the parent element. Since we were using a hodge-podge of pixel sizes, em, rem, and percentage sizes before, this change switching everything to rem, while keeping the same size relative to our old default of 16px. 16px is still the default on most browsers, for users that haven't set a larger or smaller font size.
Currently the output of a command like `./x.py build --stage 0 library/std` is this: ``` Updating only changed submodules Submodules updated in 0.02 seconds extracting [...] Compiling [...] Finished dev [unoptimized] target(s) in 17.53s Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Compling [...] Finished release [optimized + debuginfo] target(s) in 21.99s Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Build completed successfully in 0:00:51 ``` I find the part before the "Building stage0 std artifacts" a bit confusing. After this commit, it looks like this: ``` Updating only changed submodules Submodules updated in 0.02 seconds extracting [...] Building rustbuild Compiling [...] Finished dev [unoptimized] target(s) in 17.53s Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Compling [...] Finished release [optimized + debuginfo] target(s) in 21.99s Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Build completed successfully in 0:00:51 ``` The "Building rustbuild" label makes it clear what the first cargo build invocation is for. The indentation of the "Submodules updated" line indicates it is a sub-step of a parent task.
They're a bit out of date, and overly complicated.
… r=Mark-Simulacrum Label more build steps Some small improvements. r? ```@Mark-Simulacrum```
rustdoc: Clean up NestedAttributesExt trait/implementation
…, r=dtolnay Add another implementation example to Debug trait As per the discussion in: rust-lang#92276
…omez Set font size proportional to user's font size According to MDN (https://developer.mozilla.org/en-US/docs/Web/CSS/font-size), > To maximize accessibility, it is generally best to use values that are relative to the user's default font size. > Defining font sizes in px is not accessible, because the user cannot change the font size in some browsers. Note that changing font size (in browser or OS settings) is distinct from the zoom functionality triggered with Ctrl/Cmd-+. Zoom functionality increases the size of everything on the page, effectively applying a multiplier to all pixel sizes. Font size changes apply to just text. For relative font sizes, we could use `em`, as we do in several places already. However that has a problem of "compounding" (see MDN article for details). The compounding problem is nicely solved by `rem`, which make font sizes relative to the root element, not the parent element. Since we were using a hodge-podge of pixel sizes, em, rem, and percentage sizes before, this change switches everything to rem, while keeping the same size relative to our old default of 16px. 16px is still the default on most browsers, for users that haven't set a larger or smaller font size. Part of rust-lang#59845. Note: this will conflict with rust-lang#92404. We should merge that first (once it's done) and I'll resolve the merge conflicts. r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/font-size-access/std/string/struct.String.html
Explicitly pass `PATH` to the Windows exe resolver This allows for testing different `PATH`s without using the actual environment.
Extract init_env_logger to crate I've been doing some work on rustc_ast_pretty using an out-of-tree main.rs and Cargo.toml with the following: ```toml [dependencies] rustc_ast = { path = "../rust/compiler/rustc_ast" } rustc_ast_pretty = { path = "../rust/compiler/rustc_ast_pretty" } rustc_span = { path = "../rust/compiler/rustc_span" } ``` Rustc_ast_pretty helpfully uses `tracing::debug!` but I found that in order to enable the debug output, my test crate must depend on rustc_driver which is an enormously bigger dependency than what I have been using so far, and slows down iteration time because an enormous dependency tree between rustc_ast and rustc_driver must now be rebuilt after every ast change. I pulled out the tracing initialization to a new minimal rustc_log crate so that projects depending on the other rustc crates, like rustc_ast_pretty, can access the `debug!` messages in them without building all the rest of rustc.
update Miri Fixes rust-lang#92527
@bors r+ rollup=never p=7 |
📌 Commit a067346 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@181e915. Direct link to PR: <rust-lang/rust#92580> 🎉 miri on windows: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb). 🎉 miri on linux: build-fail → test-pass (cc @oli-obk @RalfJung @eddyb).
Finished benchmarking commit (181e915): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
PATH
to the Windows exe resolver #92517 (Explicitly passPATH
to the Windows exe resolver)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup