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

Merged
merged 18 commits into from
Mar 11, 2022
Merged

Rollup of 7 pull requests #94824

merged 18 commits into from
Mar 11, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Jon Gjengset and others added 18 commits March 7, 2022 17:29
PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD or sanitizers, only when
building LLVM itself. This moves the logic for setting
`-static-libstdc++` in the linker flags back to `configure_cmake` so
that it takes effect for all CMake invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers and LLD if `llvm-tools-enabled` is set but
`llvm-static-stdcpp` is not, even though previously it was only linked
statically if `llvm-static-stdcpp` was set explicitly. But that seems
more like the expected behavior anyway.
This change causes unstable lints to be ignored if the `unknown_lints`
lint is allowed. To achieve this, it also changes lints to apply as soon
as they are processed. Previously, lints in the same set were processed
as a batch and then all simultaneously applied.

Implementation of rust-lang/compiler-team#469
This also affects the `non_exhaustive_omitted_patterns` and
`must_not_suspend` lints as they are not stable. This also changes the
diagnostic level to pull from `unknown_lints` instead of always being
allow or deny.
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.

A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
…-format!-macros, r=Mark-Simulacrum

Use modern formatting for format! macros

This updates the standard library's documentation to use the new format_args syntax.
The documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.

A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).

`eprintln!("{}", e)` becomes `eprintln!("{e}")`, but `eprintln!("{}", e.kind())` remains untouched.
…=tmandry

Treat unstable lints as unknown

This change causes unstable lints to be ignored if the `unknown_lints`
lint is allowed. To achieve this, it also changes lints to apply as soon
as they are processed. Previously, lints in the same set were processed
as a batch and then all simultaneously applied.

Implementation of rust-lang/compiler-team#469
…aaaa, r=petrochenkov

[1/2] Implement macro meta-variable expressions

See rust-lang#93545 (comment)

The logic behind `length`, `index` and `count` was removed but the parsing code is still present, i.e., everything is simply ignored like `ignored`.

r? ``@petrochenkov``
…mulacrum

Statically compile libstdc++ everywhere if asked

PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place,
and was only set during linking, but accidentally also made it so that
it is no longer passed when building LLD, only when building LLVM
itself. This moves the logic for setting `-static-libstdc++` in the
linker flags to `configure_cmake` so that it takes effect for all CMake
invocations in `native.rs`.

As a side-effect, this also causes libstdc++ to be statically compiled
into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no
effect on sanitizers. It also makes it so that LLD will be compiled
statically if `llvm-tools-enabled` is set, even though previously it was
only linked statically if `llvm-static-stdcpp` was set explicitly. Both
of these seem like they match expected behavior than what was there
prior to rust-lang#93918.
…eta, r=michaelwoerister

Only emit pointer-like metadata for `Box<T, A>` when `A` is ZST

Basically copy the change in rust-lang#94043, but for debuginfo.

r? ``@michaelwoerister``

Fixes rust-lang#94725
…n-DPC

enable portable-simd doctests in Miri

With rust-lang/miri#2013 we shouldn't need to disable these tests any more. :)
…st, r=notriddle

Update browser-ui-test version

It should help with rust-lang#93784 (the important PR helping in this regard is GuillaumeGomez/browser-UI-test#273).

r? `@notriddle`
@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 Mar 10, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Mar 10, 2022

📌 Commit 456135c has been approved by Dylan-DPC

@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 Mar 10, 2022
@bors
Copy link
Contributor

bors commented Mar 10, 2022

⌛ Testing commit 456135c with merge 352e621...

@bors
Copy link
Contributor

bors commented Mar 11, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 352e621 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 11, 2022
@bors bors merged commit 352e621 into rust-lang:master Mar 11, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 11, 2022
@bors bors mentioned this pull request Mar 11, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (352e621): comparison url.

Summary: This benchmark run shows 116 relevant regressions 😿 to instruction counts.

  • Arithmetic mean of relevant regressions: 0.5%
  • Arithmetic mean of relevant improvements: -0.3%
  • Arithmetic mean of all relevant changes: 0.4%
  • Largest regression in instruction counts: 1.5% on incr-unchanged builds of unicode_normalization check

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

@rustbot rustbot added the perf-regression Performance regression. label Mar 11, 2022
@rylev
Copy link
Member

rylev commented Mar 15, 2022

@Dylan-DPC Unfortunately it seems there are many PRs that could plausibly contribute to the performance change:
* #93950 (Use modern formatting for format! macros)
* #94274 (Treat unstable lints as unknown)
* #94368 ([1/2] Implement macro meta-variable expressions)

The overall regression seems low enough that I don't think we need to consider reverting though. Unfortunately we don't have a good process for determining the culprit in cases like this where many PRs seem somewhat equally likely to be the cause.

@Dylan-DPC Dylan-DPC deleted the rollup-iamc09j branch March 15, 2022 18:28
@Dylan-DPC
Copy link
Member Author

Dylan-DPC commented Mar 15, 2022

@rylev ah.. how should we proceed with this? should I revert this rollup and re-merge the potential prs individually? (edit: or i guess just revert the 3 changes)

@rylev
Copy link
Member

rylev commented Mar 16, 2022

@Dylan-DPC I think the perf regression is large enough for us to revert. If you have the time to try to revert the three plausible culprits, then you can go for it, but don't feel pressured to!

@Dylan-DPC
Copy link
Member Author

that's fine i'll do it later today

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. perf-regression Performance regression. 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.

10 participants