Rustup

Rustup

Rustup

Rustup

add scfix test

I'm not sure if we currently *guarantee* to pass this test, but at least I was unable to get it to fail.

Cc `@cbeuw`

It was broken, and the fixed version actually fails...

remove scfix test

It was broken, and the fixed version actually fails...

Thanks `@cbeuw` !

Co-authored-by: Ralf Jung <post@ralfj.de>

Explain how to make josh authenticate with github via ssh

Without this I was unable to push, even though pushing directly to https without josh works.

Rustup

Rustup

Rustup

Implement epoll_wait

This PR continues working on rust-lang/miri#602.

This is an implementation for `sleep`, though admittedly not a good one. It just does busy waiting.

Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.23.1 to 1.24.2.
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](https://github.com/tokio-rs/tokio/commits)

---
updated-dependencies:
- dependency-name: tokio
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

…encies/tokio-1.24.2, r=RalfJung

Bump tokio from 1.23.1 to 1.24.2 in /test_dependencies

Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.23.1 to 1.24.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p>
<blockquote>
<h2>Tokio v1.24.1</h2>
<p>This release fixes a compilation failure on targets without <code>AtomicU64</code> when using rustc older than 1.63. (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5356">#5356</a>)</p>
<p><a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5356">#5356</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5356">tokio-rs/tokio#5356</a></p>
<h2>Tokio v1.24.0</h2>
<p>The highlight of this release is the reduction of lock contention for all I/O operations (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5300">#5300</a>). We have received reports of up to a 20% improvement in CPU utilization and increased throughput for real-world I/O heavy applications.</p>
<h3>Fixed</h3>
<ul>
<li>rt: improve native <code>AtomicU64</code> support detection (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5284">#5284</a>)</li>
</ul>
<h3>Added</h3>
<ul>
<li>rt: add configuration option for max number of I/O events polled from the OS
per tick (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5186">#5186</a>)</li>
<li>rt: add an environment variable for configuring the default number of worker
threads per runtime instance (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/4250">#4250</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>sync: reduce MPSC channel stack usage (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5294">#5294</a>)</li>
<li>io: reduce lock contention in I/O operations  (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5300">#5300</a>)</li>
<li>fs: speed up <code>read_dir()</code> by chunking operations (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5309">#5309</a>)</li>
<li>rt: use internal <code>ThreadId</code> implementation (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5329">#5329</a>)</li>
<li>test: don't auto-advance time when a <code>spawn_blocking</code> task is running (<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5115">#5115</a>)</li>
</ul>
<p><a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5186">#5186</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5186">tokio-rs/tokio#5186</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5294">#5294</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5294">tokio-rs/tokio#5294</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5284">#5284</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5284">tokio-rs/tokio#5284</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/4250">#4250</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/4250">tokio-rs/tokio#4250</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5300">#5300</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5300">tokio-rs/tokio#5300</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5329">#5329</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5329">tokio-rs/tokio#5329</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5115">#5115</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5115">tokio-rs/tokio#5115</a>
<a href="https://github-redirect.dependabot.com/tokio-rs/tokio/issues/5309">#5309</a>: <a href="https://github-redirect.dependabot.com/tokio-rs/tokio/pull/5309">tokio-rs/tokio#5309</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/tokio-rs/tokio/commits">compare view</a></li>
</ul>
</details>
<br />

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tokio&package-manager=cargo&previous-version=1.23.1&new-version=1.24.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting ``@dependabot` rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` use these labels` will set the current labels as the default for future PRs for this repo and language
- ``@dependabot` use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- ``@dependabot` use these assignees` will set the current assignees as the default for future PRs for this repo and language
- ``@dependabot` use this milestone` will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/rust-lang/miri/network/alerts).

</details>

Rustup

Rustup

Rustup

Rustup

This patch adds a few tests to assert the current behavior when passing
data across an await point. This will help to test out an upcoming fix
for the issue of arguments in async functions growing in size because of
the generator upvar that is generated when we desugar the async
function.

See rust-lang#62958

Also relates to rust-lang#107500

Co-authored-by: Ralf Jung <post@ralfj.de>

Rustup

Add tests for moving data across await point

This patch adds a few tests to assert the current behavior when passing data across an await point. This will help to test out an upcoming fix for the issue of arguments in async functions growing in size because of the generator upvar that is generated when we desugar the async function.

See rust-lang#62958

Also relates to rust-lang#107500

FYI `@oli-obk` `@pnkfelix`

Rustup

…ust deletes code

Rustup

Previously, there were two queries to check whether a type allows the
0x01 or zeroed bitpattern.

I am planning on adding a further initness to check, truly uninit for
MaybeUninit, which would make this three queries. This seems overkill
for such a small feature, so this PR unifies them into one.

This shim is required for `core::hint::spin_loop` on `arm` targets

This makes sure that the interface of `miri_host_to_target_path` is compatible with `CStr` for targets where `c_char` is unsigned (such as ARM). This commit changes the signature of `miri_host_to_target_path` in the README and in all test cases.

Specifically `aarch64-unknown-linux-gnu` and `arm-unknown-linux-gnueabi`

Co-authored-by: Ralf Jung <post@ralfj.de>

cargo-miri: bump `rustc_tools_util` crate

This dedupes crate versions in rust repo.

Get Miri working on ARM

- Add a shim for `llvm.arm.hint`, which is required by `core::hint::spin_loop` on `arm` targets. The shim simply calls `yield_active_thread` on a YIELD hint, just like the shim for `llvm.aarch64.isb` that's already present.
- Change the signature of `miri_host_to_target_path` to use `c_char` instead of `i8`, to make it compatible with `CStr` on targets where `c_char` is unsigned. The implementation of `miri_host_to_target_path` accesses the memory as bytes and does not need to be adjusted.
- Enable ARM targets in CI. Specifically, `aarch64-unknown-linux-gnu` and `arm-unknown-linux-gnueabi` on the Linux host.

Since all tests also pass for `aarch64-unknown-linux-gnu` I took the liberty of adding that target to CI as well.

Fixes rust-lang#2791

Rustup

I have been reviewing PRs for a long while during weekends, however
recently I’ve been having trouble commiting to that as well. Every
weekend I’ve been spending working on a house.

I may return myself to the rotation in a couple of months. I may also
just start ninja'ing up some PRs from the PR list whenever I find some
time for reviews again, without putting myself back into the rotation,
in acknowledgement that me being able to review every weekend or every
second weekend is not a great experience for the contributors waiting on
reviews from me.

…ecializable-rpitits, r=lcnr

Don't project specializable RPITIT projection

This effective rejects specialization + RPITIT/AFIT (usages of `impl Trait` in traits) because the implementation is significantly complicated over making regular "default" trait method bodies work.

I have another PR that experimentally fixes all this, but the code may not be worth investing in.

…, r=compiler-errors

Unify validity checks into a single query

Previously, there were two queries to check whether a type allows the 0x01 or zeroed bitpattern.

I am planning on adding a further initness to check in rust-lang#100423, truly uninit for MaybeUninit, which would make this three queries. This seems overkill for such a small feature, so this PR unifies them into one.

I am not entirely happy with the naming and key type and open for improvements.

r? oli-obk

…lbertlarsan68

bootstrap: Update the output of the `check` descriptions

This should bring the output from `x check` in line with the changes in rust-lang#108171

…r=compiler-errors

Make `match` arm comma suggestion more clear

Fixes rust-lang#108472

Merge diagnostic_items duplicate diagnostics

To deduplicate how we diagnose duplication.

…ddle

Clean up JS files code a bit

I mostly moved values closer to where they are used to make the code reading easier.

r? ```@notriddle```

update Miri

r? ``@ghost``

…mpiler-errors

Don't trigger error for ReError when other region is empty.

Fixes [rust-lang#107988](rust-lang#107988)

Remove @nagisa from review rotation

I have been reviewing PRs for a long while during weekends, however recently I’ve been having trouble commiting to that as well. Every weekend I’ve been spending working on a house.

I may return myself to the rotation in a couple of months. I may also just start ninja'ing up some PRs from the PR list whenever I find some time for reviews again, without putting myself back into the rotation, in acknowledgement that me being able to review every weekend or every second weekend is not a great experience for the contributors waiting on reviews from me.