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 9 pull requests #98486

Merged
merged 32 commits into from
Jun 25, 2022
Merged

Rollup of 9 pull requests #98486

merged 32 commits into from
Jun 25, 2022

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ChrisDenton and others added 30 commits April 26, 2022 00:13
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
It's possible that a file in the directory is pending deletion. In that case we might succeed after a few attempts.
rust-lang#91318 introduced a trait for infallible folders distinct from the fallible version.  For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible.  Moreover the `Error` associated type was defined on the infallible trait!  It's so absurd that it has me questioning whether I was entirely sane.

This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation).  This of course makes much more sense!  It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.

There is one downside however: folders expose a `tcx` accessor method.  Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate.  Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate.  If desired, I can submit that as a separate PR.

r? @jackh726
…ssoc type

use `def_ident_span` , `body_owner_def_id` instead of `in_progress_typeck_results`, `guess_head_span`

use `body_id.owner` directly

add description to label
Windows: Iterative `remove_dir_all`

This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.

Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).
…vulnerability, r=cuviper

Mitigate MMIO stale data vulnerability

Intel publicly disclosed the MMIO stale data vulnerability on June 14. To mitigate this vulnerability, compiler changes are required for the `x86_64-fortanix-unknown-sgx` target.
cc: ````@jethrogb````
…nkov

Set relocation_model to Pic on emscripten target

So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and `-Zbuild-std` to rebuild std with relocations).
`````@sbc100`````
…r=Amanieu

Leak pthread_{mutex,rwlock}_t if it's dropped while locked.

Fixes rust-lang#85434.
…ion, r=compiler-errors

Point to type parameter definition when not finding variant, method and associated item

fixes rust-lang#77391
…jackh726

Reverse folder hierarchy

rust-lang#91318 introduced a trait for infallible folders distinct from the fallible version.  For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible.  Moreover the `Error` associated type was defined on the infallible trait!  It's so absurd that it has me questioning whether I was entirely sane.

This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation).  This of course makes much more sense!  It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.

There is one downside however: folders expose a `tcx` accessor method.  Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate.  Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate.  If desired, I can submit that as a separate PR.

r? ````@jackh726````
Add tracking issues to `--extern` option docs.
…nant-cast, r=lcnr

Use correct substs in enum discriminant cast

Fixes rust-lang#97634

r? ```@lcnr```
…=compiler-errors

Suggest defining variable as mutable on `&mut _` type mismatch in pats

Suggest writing `mut a` where `&mut a` was written but a non-ref type provided.

Since we still don't have "apply either one of the suggestions but not both" kind of thing, the interaction with the suggestion of removing `&[mut]` or moving it to the type is weird, and idk how to make it better..

r? ``@compiler-errors``
@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. rollup A PR which is a rollup labels Jun 25, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Jun 25, 2022

📌 Commit 1f923c2 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 Jun 25, 2022
@bors
Copy link
Contributor

bors commented Jun 25, 2022

⌛ Testing commit 1f923c2 with merge 8aab472...

@bors
Copy link
Contributor

bors commented Jun 25, 2022

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 8aab472 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 25, 2022
@bors bors merged commit 8aab472 into rust-lang:master Jun 25, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jun 25, 2022
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #98486!

Tested on commit 8aab472.
Direct link to PR: #98486

💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jun 25, 2022
Tested on commit rust-lang/rust@8aab472.
Direct link to PR: <rust-lang/rust#98486>

💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8aab472): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

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

Cycles

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

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

  2. number of relevant changes 2

@matthiaskrgr matthiaskrgr deleted the rollup-u7m508x branch July 30, 2022 10:33
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.