Backport rust-lang/stdarch#1818 for 1.88 by Amanieu · Pull Request #142694 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits27 Checks6 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
…nglo
[beta-1.88] Update cargo
1 commits in 7918c7eb59614c39f1c4e27e99d557720976bdd7..873a0649350c486caf67be772828a4f36bb4734c 2025-04-27 09:44:23 +0000 to 2025-05-10 06:10:32 -0500
- [beta-1.88] fix(rustc): Don't panic on unknown bins (rust-lang/cargo#15515)
r? ghost
(cherry picked from commit 577e82f)
(cherry picked from commit 448b7af)
Unfortunately, multiple people are reporting linker warnings related to
__rust_no_alloc_shim_is_unstable after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for __rust_no_alloc_shim_is_unstable.
This reverts commit c8b7f32, reversing changes made to 667247d.
(cherry picked from commit 734a5b1)
…ad disable problematic test
(cherry picked from commit 6128fca)
(cherry picked from commit 66d47c1)
…ages
At the moment, it seems like Windows Server 2025 20250504.1.0 is misconfigured causing insufficient disk space failures. Temporarily go back to Windows Server 2022 in the hope that those are not also misconfigured.
(cherry picked from commit f4ce73e)
This is needed to make the cache work after moving CI from the rust-lang-ci org to rust-lang.
(cherry picked from commit eb53032)
To make it easier to migrate off the rust-lang-ci/rust repository.
(cherry picked from commit 7d32303)
(cherry picked from commit 806cd12)
This will be used to access secrets once we move off rust-lang-ci.
(cherry picked from commit c7a2694)
(cherry picked from commit 321db85)
(cherry picked from commit f01bbfc)
If an attribute is re-emitted by a macro, the incorrect edition was used to emit warnings for unsafe attributes
(cherry picked from commit 2c82574)
[beta] backports
- x86 (32/64): go back to passing SIMD vectors by-ptr rust-lang#141309
- use correct edition when warning for unsafe attributes rust-lang#142261
r? cuviper
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
⚠️ Warning ⚠️
- Pull requests are usually filed against the master branch for this repo, but this one is against beta. Please double check that you specified the right target!
- Some commits in this PR modify submodules.
- There are issue links (such as
#123) in the commit messages of the following commits.
Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
This was referenced
Jun 20, 2025
It would be useful to have another crater run with this backport, just in case.
Did it show up previously in crater? What do you expect to see (or not)?
There are actually 2 accidental stabilizations, done at separate times:
- The
vbslintrinsics for f16 were accidentally stabilized in 1.88 (current beta). - The
float16x{4,8}_ttypes were accidentally stabilized in 1.87 (current stable).
It is possible in theory that some people may be already using the float16xN_t types, although that is unlikely since all of the intrinsics that use this type are still unstable.
OK, but crater is still only x86-64 Linux AFAIK, so these aarch64 changes wouldn't show up anyway, right?
bors added a commit that referenced this pull request
rust-bors bot added a commit that referenced this pull request
bors added a commit that referenced this pull request
OK, but crater is still only x86-64 Linux AFAIK, so these
aarch64changes wouldn't show up anyway, right?
Good point, I'd forgotten about that. Perhaps we could do an aarch64 check-only crater run?
Conflicts are because the beta branch just moved to 1.89. I'm going to close this, but we'll still need to check the crater results in #141588.
Labels
Accepted for backporting to the compiler in the beta channel.
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.