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 #93655

Merged
merged 26 commits into from
Feb 5, 2022
Merged

Rollup of 7 pull requests #93655

merged 26 commits into from
Feb 5, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joshtriplett and others added 26 commits January 1, 2022 15:57
Continue supporting -Z instrument-coverage for compatibility for now,
but show a deprecation warning for it.

Update uses and documentation to use the -C option.

Move the documentation from the unstable book to stable rustc
documentation.
llvm-tools-preview is still experimental, so document it as such, and
don't use it in the examples.
…VM versions

The instrument-coverage option is stable; the details of the profile
data format are not.

Recommend llvm-tools-preview as the preferred alternative to obtain a
compatible version of the LLVM tools, rather than finding LLVM tools
elsewhere.
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
…tions

These options primarily exist to work around bugs, and those bugs have
largely been fixed. Avoid stabilizing them, so that we don't have to
support them indefinitely.
This code and comment appear to be out of date.
`CrateLocator::find_library_crate` is the only caller of this function
and it handles rlib vs dylib overlap itself (see
`CrateLocator::extract_lib`) after inspecting all the files present, so
it doesn't need to see them in any particular order.
It's returned from `FileSearch::search` but it's only used to print some
debug info.
It has only a single callsite, and having all the code in one place will
make it possible to optimize the search.
Currently, it can be `None` if the conversion from `OsString` fails, in
which case all searches will skip over the `SearchPathFile`.

The commit changes things so that the `SearchPathFile` just doesn't get
created in the first place. Same behaviour, but slightly simpler code.
Previously, tidy-html5 (`tidy`) would complain about a few things in our
HTML. The main thing is that `<summary>` tags can't contain `<div>`s.
That's easily fixed by changing out the `<div>`s for `<span>`s with
`display: block`.

However, there's also a rule that `<span>`s can't contain heading
elements. `<span>` permits only "phrasing content"
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span, and
`<h3>` (and friends) are "Flow content, heading content, palpable
content".
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements

We have a wrapping `<div>` that goes around each `<h3>`/`<h4>`,
etc. We turn that into a `<section>` rather than a `<span>` because
`<section>` permits "flow content".
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section

After this change we get only three warnings from tidy, run on
struct.String.html:

line 6 column 10790 - Warning: trimming empty <span>
line 1 column 1118 - Warning: <link> proprietary attribute "disabled"
line 1 column 1193 - Warning: <link> proprietary attribute "disabled"

The empty `<span>` is a known issue - there's a span in front of the
search box to work around a strange Safari issue.

The `<link>` attributes are the non-default stylesheets. We can probably
refactor theme application to avoid using this proprietary "disabled"
attribute.
The function gets the inner value, cloning only if necessary.
By introducing prefix and suffix variables for all file types, and
renaming some variables.
…overage, r=wesleywiser

Stabilize `-Z instrument-coverage` as `-C instrument-coverage`

(Tracking issue for `instrument-coverage`: rust-lang#79121)

This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)

Many, many people have tested this support, and there are numerous reports of it working as expected.

Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.

Addressing questions raised in the tracking issue:

> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)

This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.

> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?

This stabilization PR depends on rust-lang#90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).

> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.

Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.

The [tracking issue](rust-lang#79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.

The original `-Z instrument-coverage` support went through a compiler-team MCP at rust-lang/compiler-team#278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
…m-ou-se

impl `Arc::unwrap_or_clone`

The function gets the inner value, cloning only if necessary. The conversation started on [`irlo`](https://internals.rust-lang.org/t/arc-into-inner/15707). If the reviewer think the PR has potential to be merged, and does not need an RFC, then I will create the corresponding tracking issues and update the PR.

## Alternative names

 - `into_inner`
 - `make_owned`
 - `make_unique`
 - `take_*` (`take_inner`?)
…=yaahc

kmc-solid: Fix off-by-one error in `SystemTime::now`

Fixes a miscalculation of `SystemTime`  on the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.

Unlike the identically-named libc counterpart `tm::tm_mon`, `SOLID_RTC_TIME::tm_mon` contains a 1-based month number.
…omez

Emit more valid HTML from rustdoc

Previously, tidy-html5 (`tidy`) would complain about a few things in our HTML. The main thing is that `<summary>` tags can't contain `<div>`s. That's easily fixed by changing out the `<div>`s for `<span>`s with `display: block`.

However, there's also a rule that `<span>`s can't contain heading elements. `<span>` permits only "phrasing content" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span, and `<h3>` (and friends) are "Flow content, heading content, palpable content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements

We have a wrapping `<div>` that goes around each `<h3>`/`<h4>`, etc. We turn that into a `<section>` rather than a `<span>` because `<section>` permits "flow content". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section

After this change we get only three warnings from tidy, run on struct.String.html:

line 6 column 10790 - Warning: trimming empty <span>
line 1 column 1118 - Warning: <link> proprietary attribute "disabled"
line 1 column 1193 - Warning: <link> proprietary attribute "disabled"

The empty `<span>` is a known issue - there's a span in front of the search box to work around a strange Safari issue.

The `<link>` attributes are the non-default stylesheets. We can probably refactor theme application to avoid using this proprietary "disabled" attribute.

We can suppress those warnings with flags to tidy, and get a run that returns 0 (success):

```
tidy -o /dev/null -quiet --drop-empty-elements no --warn-proprietary-attributes no build/x86_64-unknown-linux-gnu/doc/std/string/trait.ToString.html
```

Note: this requires the latest version of tidy-html5, built from https://github.com/htacg/tidy-html5. Older versions (including the default version on Ubuntu 21.10) think `<section>` can't occur inside `<summary>`.

Demo: https://rustdoc.crud.net/jsha/fix-rustdoc-html/std/string/struct.String.html

r? `@GuillaumeGomez`
…rate, r=petrochenkov

Clean up `find_library_crate`

Some clean-ups.

r? `@petrochenkov`
doc: use U+2212 for minus sign in integer MIN/MAX text

Closes rust-lang#90793.
…r=the8472

Fix `isize` optimization in `StableHasher` for big-endian architectures

This PR fixes a problem with the stable hash optimization introduced in rust-lang#93432. As `@michaelwoerister` has [found out](rust-lang#93432 (comment)), the original implementation wouldn't produce the same hash on little/big architectures.

r? `@the8472`
@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 Feb 4, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Feb 4, 2022

📌 Commit 2d62bd0 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 Feb 4, 2022
@bors
Copy link
Contributor

bors commented Feb 4, 2022

⌛ Testing commit 2d62bd0 with merge 56abce6f9c5db404165bdbde0d4ba41f39692951...

@bors
Copy link
Contributor

bors commented Feb 5, 2022

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 5, 2022
@matthiaskrgr
Copy link
Member Author

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 5, 2022
@bors
Copy link
Contributor

bors commented Feb 5, 2022

⌛ Testing commit 2d62bd0 with merge 4c55c83...

@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@klensy
Copy link
Contributor

klensy commented Feb 5, 2022

A job failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)


#93329 but now on i686-msvc-1, --build=i686-pc-windows-msvc, make ci-subset-1, windows-latest-xl

@bors
Copy link
Contributor

bors commented Feb 5, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 4c55c83 to master...

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (4c55c83): comparison url.

Summary: This benchmark run did not return any relevant results. 6 results were found to be statistically significant but too small to be relevant.

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-dm88b02 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.