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

Rollup of 7 pull requests #92580

Merged
merged 18 commits into from
Jan 5, 2022
Merged

Rollup of 7 pull requests #92580

merged 18 commits into from
Jan 5, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

vacuus and others added 18 commits December 23, 2021 17:58
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.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 5, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Jan 5, 2022

📌 Commit a067346 has been approved by matthiaskrgr

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jan 5, 2022
@bors
Copy link
Contributor

bors commented Jan 5, 2022

⌛ Testing commit a067346 with merge 181e915...

@bors
Copy link
Contributor

bors commented Jan 5, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 181e915 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 5, 2022
@bors bors merged commit 181e915 into rust-lang:master Jan 5, 2022
@rustbot rustbot added this to the 1.59.0 milestone Jan 5, 2022
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #92580!

Tested on commit 181e915.
Direct link to PR: #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).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jan 5, 2022
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).
@rust-timer
Copy link
Collaborator

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

@matthiaskrgr matthiaskrgr deleted the rollup-nzyn65y branch February 13, 2022 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. 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.