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 6 pull requests #99652

Merged
merged 12 commits into from
Jul 24, 2022
Merged

Rollup of 6 pull requests #99652

merged 12 commits into from
Jul 24, 2022

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ChrisDenton and others added 12 commits July 15, 2022 23:51
These test can fail on stage 1
The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.
…r=Mark-Simulacrum

Make `ui-fulldeps/gated-plugins` and `ui-fulldeps/multiple-plugins` tests stage 2 only

These test can fail on stage 1.

Fixes rust-lang#99295
…rk-Simulacrum

Add some additional double-adjustment regression tests

I accidentally missed these when I rebased rust-lang#98785

cc rust-lang#98894 and rust-lang#98897
…-item, r=lcnr

Do not resolve associated const when there is no provided value

Fixes rust-lang#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.

----

The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.

This root issue becomes problematic (as in rust-lang#98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.

I'm not exactly sure _why_ this bug arises due to rust-lang#96591 -- perhaps valtrees are evaluated more eagerly than in the old system?

r? ``@oli-obk`` or ``@lcnr`` since y'all are familiar with const eval and reviewed rust-lang#96591, though feel free to reassign.

This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
Mark atomics as unsupported on thumbv6m

The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.
Lock stdout once when listing tests

This is a marginal optimization for normal operation, but for `cargo miri nextest list` (which is invoked by `cargo miri nextest run`) this knocks the startup time on `regex` down from 87 seconds to 17 seconds. Still slow, but a nice 5x improvement.
…triddle

Remove Clean trait implementation for hir::Ty and middle::Ty

While going through the code, I realized that the "remove the Clean trait" effort which was started a while ago was never finished.

The idea behind it was to make it much simpler to go through the different clean steps (which is definitely not easy when you just have `something.clean(cx)`).

I'm planning to finish this effort.

cc ``@camelid``
r? ``@notriddle``
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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 Jul 23, 2022
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=6 rollup=never

@bors
Copy link
Contributor

bors commented Jul 23, 2022

📌 Commit d87a13f has been approved by GuillaumeGomez

It is now in the queue for this repository.

@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 Jul 23, 2022
@bors
Copy link
Contributor

bors commented Jul 23, 2022

⌛ Testing commit d87a13f with merge fcad918...

@bors
Copy link
Contributor

bors commented Jul 24, 2022

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing fcad918 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 24, 2022
@bors bors merged commit fcad918 into rust-lang:master Jul 24, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jul 24, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (fcad918): comparison url.

Instruction count

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
0.4% 0.4% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) N/A N/A 0

Max RSS (memory usage)

Results
  • Primary benchmarks: 🎉 relevant improvement found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
2.5% 2.5% 1
Improvements 🎉
(primary)
-4.0% -4.0% 1
Improvements 🎉
(secondary)
-4.1% -4.1% 1
All 😿🎉 (primary) -4.0% -4.0% 1

Cycles

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
2.6% 2.6% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-2.7% -2.7% 1
All 😿🎉 (primary) N/A N/A 0

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

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

@GuillaumeGomez GuillaumeGomez deleted the rollup-38v0x7y branch July 24, 2022 11:15
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-libs Relevant to the library 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.

8 participants