Rustc pull update #2518
Merged
Rustc pull update #2518
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 040e2f8b9ff2d76fbe2146d6003e297ed4532088 Filtered ref: cf4d00a666607e356e410a820ae07eeba28a9b53 This merge was created using https://github.com/rust-lang/josh-sync.
Perform the first rustc pull.. for the second time
use `splat` for the aarch64/arm dup intrinsics
aarch64: use `core::intrinsics::simd` for integer min/max
`intrinsic-test`: use runner also for rust
loongarch: Add basic support for LoongArch32
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 82310651b93a594a3fd69015e1562186a080d94c Filtered ref: e13c0be8f13737c64082b89ce834546079767ac4 This merge was created using https://github.com/rust-lang/josh-sync.
compiler-builtins subtree update Subtree update of `compiler-builtins` to rust-lang/compiler-builtins@2cdde03. Created using https://github.com/rust-lang/josh-sync. Fixes: rust-lang/rust#144076 r? `@ghost`
gpu offload host code generation r? ghost This will generate most of the host side code to use llvm's offload feature. The first PR will only handle automatic mem-transfers to and from the device. So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch. Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening. A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU. A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues. I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work. This work will also be compatible with std::autodiff, so one can differentiate GPU kernels. Tracking: - rust-lang/rust#131513
Lower extra lifetimes before normal generic params. Fixes rust-lang/rust#143413
Constify Try, From, TryFrom and relevant traits
Implement `check` for compiletest and RA using tool macro Small cleanup to reduce the number of places that require custom check steps. Of course I had to include one mini hack because of Rust Analyzer.. but I think it's worth it here. r? ````@jieyouxu````
rustc_public: de-StableMIR-ize This PR updates relevant docs about StableMIR, basically just rewording StableMIR/SMIR to rustc_public/rustc_public's IR. The README.md in the `rustc_public` crate is out-dated. I plan to rewrite it after we fork rustc_public into its own repository. This PR doesn't change the fact that we still use `-Z unpretty=stable-mir` as a rustc parameter for printing the IR, since I feel it's a bit verbose and weird if we use `-Z unpretty=rustc-public-ir`. I was wondering if we can have a short and easy alias for rustc_public's IR.
clippy: make tests work in stage 1 This finally fixes rust-lang/rust#78717 :) Similar to what Miri already does, the clippy test step needs to carefully consider which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but rust-lang/cargo#4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details. Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense. Cc ```@flip1995``` ```@Kobzol```
Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang/rust#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](rust-lang/rust#143834 (comment)), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
Add approval blocking labels for new bors If a PR contains these labels, new bors won't let anyone approve it. We don't merge PRs using new bors yet, ofc, but I wanted to prepare this so that I don't forget about it. This was proposed here: [#t-lang/meetings > Triage meeting 2025-07-23 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-23/near/529407150) and implemented [here](rust-lang/bors#367). CC ````@RalfJung```` r? ````@oli-obk````
Remove the ptr_unique lang item Miri no longer uses it since rust-lang/miri#4307.
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to cca2337. Created using https://github.com/rust-lang/josh-sync. r? ```@ghost```
opt-dist: make `artifact-dir` an absolute path for `opt-dist local` ...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some intermediate steps fail due to path being relative to an active directory r? Kobzol try-job: dist-x86_64-msvc try-job: dist-x86_64-linux
Rollup of 14 pull requests Successful merges: - rust-lang/rust#142097 (gpu offload host code generation) - rust-lang/rust#143430 (Lower extra lifetimes before normal generic params.) - rust-lang/rust#143768 (Constify Try, From, TryFrom and relevant traits) - rust-lang/rust#143816 (Implement `check` for compiletest and RA using tool macro) - rust-lang/rust#143985 (rustc_public: de-StableMIR-ize) - rust-lang/rust#144027 (clippy: make tests work in stage 1) - rust-lang/rust#144080 (Mitigate `#[align]` name resolution ambiguity regression with a rename) - rust-lang/rust#144176 (Add approval blocking labels for new bors) - rust-lang/rust#144187 (fix handling of base address for TypeId allocations) - rust-lang/rust#144212 (Remove the ptr_unique lang item) - rust-lang/rust#144243 (Subtree update of `rust-analyzer`) - rust-lang/rust#144246 (Don't use another main test file as auxiliary) - rust-lang/rust#144251 (rustc-dev-guide subtree update) - rust-lang/rust#144254 (opt-dist: make `artifact-dir` an absolute path for `opt-dist local`) r? `@ghost` `@rustbot` modify labels: rollup
flt2dec: replace for loop by iter_mut Perf is explored in rust-lang/rust#144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@5531955. Created using https://github.com/rust-lang/josh-sync. I saw that there were non-trivial changes made to `std_detect` in `stdarch` recently. So I want to get them merged here before we move forward with rust-lang/rust#143412. r? `@folkertdev`
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of rust-lang/rust#144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang/rust#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
Implement AST visitors using a derive macro. AST visitors are large and error-prone beasts. This PR attempts to write them using a derive macro. The design uses three traits: `Visitor`, `Visitable`, `Walkable`. - `Visitor` is the trait implemented by downstream crates, it lists `visit_stuff` methods, which call `Walkable::walk_ref` by default; - `Walkable` is derived using the macro, the generated `walk_ref` method calls `Visitable::visit` on each component; - `Visitable` is implemented by `common_visitor_and_walkers` macro, to call the proper `Visitor::visit_stuff` method if it exists, to call `Walkable::walk_ref` if there is none. I agree this is quite a lot of spaghetti macros. I'm open to suggestions on how to reduce the amount of boilerplate code. If this PR is accepted, I believe the same design can be used for the HIR visitor.
Move `std_detect` into stdlib This PR moves the `std_detect` crate from `stdarch` to be a part of rust-lang/rust instead. The first commit actually moves the whole directory from the stdarch Josh subtree, so that git blame history is kept intact. Then I had to make a few changes to appease `tidy`. The most complex thing here is porting the tests. We can't have `std_detect` both in r-l/r and stdarch, because they could get desynchronized, so we have to perform the move more or less "atomically", which means that we also have to port all the existing `std_detect` tests from the `stdarch` repository. The stdarch repo runs the following `std_detect` tests: ### Build The `build-std-detect.sh` script (https://github.com/rust-lang/stdarch/blob/e2b6512aed87df45294ae680181eeef7a802cd95/ci/build-std-detect.sh) builds `std_detect` using the nightly compiler for several targets. This will be subsumed by normal `x build library` on our Tier 1/2 targets. However, the stdarch repository also tests the following targets: - aarch64-unknown-freebsd - armv6-unknown-freebsd - powerpc-unknown-freebsd - powerpc64-unknown-freebsd - aarch64-unknown-openbsd Which we don't build/test on our CI currently. I think we have mostly two options here: 1) Ignore these targets 2) Create a special CI job that will build stage 1 rustc and then cross-compile std (or just the `std_detect` crate?) for these targets. ### Documentation The `dox.sh` script (https://github.com/rust-lang/stdarch/blob/3fec5adcd52a815f227805d4959a25b6402c7fd5/ci/dox.sh) builds and documents `std_detect` for several targets. All of them are Tier 2/we have `dist-` jobs for them, so I think that we can just skip this and let our normal CI subsume it? ### Tests The `run.sh` script (https://github.com/rust-lang/stdarch/blob/1b201cec2cca7465602a65ed6ae60517224b15f3/ci/run.sh) runs `cargo test` on `std_detect` with a bunch of variations of feature flags. This will be subsumed by `x test library` in our CI. The only problem is that `stdarch` runs these tests for a ludicrous number of targets: ``` - tuple: i686-unknown-linux-gnu - tuple: x86_64-unknown-linux-gnu - tuple: arm-unknown-linux-gnueabihf - tuple: armv7-unknown-linux-gnueabihf - tuple: aarch64-unknown-linux-gnu - tuple: aarch64_be-unknown-linux-gnu - tuple: riscv32gc-unknown-linux-gnu - tuple: riscv64gc-unknown-linux-gnu - tuple: powerpc-unknown-linux-gnu - tuple: powerpc64-unknown-linux-gnu - tuple: powerpc64le-unknown-linux-gnu - tuple: s390x-unknown-linux-gnu - tuple: i586-unknown-linux-gnu - tuple: nvptx64-nvidia-cuda - tuple: thumbv6m-none-eabi - tuple: thumbv7m-none-eabi - tuple: thumbv7em-none-eabi - tuple: thumbv7em-none-eabihf - tuple: loongarch64-unknown-linux-gnu - tuple: wasm32-wasip1 - tuple: x86_64-apple-darwin - tuple: x86_64-apple-ios-macabi - tuple: aarch64-apple-darwin - tuple: aarch64-apple-ios-macabi - tuple: x86_64-pc-windows-msvc - tuple: i686-pc-windows-msvc - tuple: aarch64-pc-windows-msvc - tuple: x86_64-pc-windows-gnu - tuple: aarch64-unknown-linux-gnu - tuple: aarch64_be-unknown-linux-gnu - tuple: armv7-unknown-linux-gnueabihf - tuple: loongarch64-unknown-linux-gnu - tuple: powerpc-unknown-linux-gnu - tuple: powerpc64-unknown-linux-gnu - tuple: powerpc64le-unknown-linux-gnu - tuple: riscv32gc-unknown-linux-gnu - tuple: riscv64gc-unknown-linux-gnu - tuple: s390x-unknown-linux-gnu - tuple: x86_64-unknown-linux-gnu - tuple: aarch64-apple-darwin - tuple: aarch64-apple-ios-macabi ``` We definitely do not run *tests* for all of these targets on our CI. # Outcome We have decided to just subsume std_detect tests by our normal test suite for now, and not create a separate CI job. Therefore, this PR performs the following changes in target testing for `std_detect`: The following T3 targets would go from "build" to "nothing": ``` aarch64-unknown-freebsd (T3) armv6-unknown-freebsd (T3) powerpc-unknown-freebsd (T3) powerpc64-unknown-freebsd (T3) aarch64-unknown-openbsd (T3) ``` The following T3 targets would go from "test" to "nothing": ``` aarch64_be-unknown-linux-gnu (T3) riscv32gc-unknown-liux-gnu (T3) ``` The following T2 targets would go from "test" to "build": ``` arm-unknown-linux-gnueabihf (T2) armv7-unknown-linux-gnueabihf (T2) riscv64gc-unknown-linux-gnu (T2) powerpc-unknown-linux-gnu (T2) powerpc64-unknown-linux-gnu (T2) powerpc64le-unknown-linux-gnu (T2) s390x-unknown-linux-gnu (T2) i586-unknown-linux-gnu (T2) loongarch64-unknown-linux-gnu (T2) wasm32-wasip1 (T2) x86_64-apple-ios-macabi (T2) aarch64-apple-ios-macabi (T2) aarch64-pc-windows-msvc (T2) armv7-unknown-linux-gnueabihf (T2) loongarch64-unknown-linux-gnu (T2) powerpc-unknown-linux-gnu (T2) ``` I have confirmed in rust-lang/stdarch#1873 that the current version of this PR would pass stdarch's CI testsuite. r? `@ghost` try-job: armhf-gnu try-job: arm-android
Consider parent predicates in ImpossiblePredicates pass. This pass is double edged. It avoids some ICEs (yay!) but also degrades diagnostics from constant evaluation. Fixes rust-lang/rust#121363 Fixes rust-lang/rust#131507 Fixes rust-lang/rust#140100 Fixes rust-lang/rust#140365
Enforce that PR CI jobs are a subset of Auto CI jobs modulo carve-outs ### Background Currently, it is possible for a PR with red PR-only CI to pass Auto CI, then all subsequent PR CI runs will be red until that is fixed, even in completely unrelated PRs. For instance, this happened with PR-CI-only Spellcheck (rust-lang/rust#144183). See more discussions at [#t-infra > Spellcheck workflow now fails on all PRs (tree bad?)](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spellcheck.20workflow.20now.20fails.20on.20all.20PRs.20.28tree.20bad.3F.29/with/529769404). ### CI invariant: PR CI jobs are a subset of Auto CI jobs modulo carve-outs To prevent red PR CI in completely unrelated subsequent PRs and PR CI runs, we need to maintain an invariant that **PR CI jobs are a subset of Auto CI jobs modulo carve-outs**. This is **not** a "strict" subset relationship: some jobs necessarily have to differ under PR CI and Auto CI environments, at least in the current setup. Still, we can try to enforce a weaker "subset modulo carve-outs" relationship between CI jobs and their corresponding Auto jobs. For instance: - `x86_64-gnu-tools` will have `auto`-only env vars like `DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`. - `tidy` will want to `continue_on_error: true` in PR CI to allow for more "useful" compilation errors to also be reported, whereas it should be `continue_on_error: false` in Auto CI to prevent wasting Auto CI resources. The **carve-outs** are: 1. `env` variables. 2. `continue_on_error`. We enforce this invariant through `citool`, so only affects job definitions that are handled by `citool`. Notably, this is not sufficient *alone* to address the CI-only Spellcheck issue (rust-lang/rust#144183). To carry out this enforcement, we modify `citool` to auto-register PR jobs as Auto jobs with `continue_on_error` overridden to `false` **unless** there's an overriding Auto job for the PR job of the same name that only differs by the permitted **carve-outs**. ### Addressing the Spellcheck PR-only CI issue Note that Spellcheck currently does not go through `citool` or `bootstrap`, and is its own GitHub Actions workflow. To actually address the PR-CI-only Spellcheck issue (rust-lang/rust#144183), and carry out the subset-modulo-carve-outs enforcement universally, this PR additionally **removes the current Spellcheck implementation** (a separate GitHub Actions Workflow). That is incompatible with Homu unless we do some hacks in the main CI workflow. This effectively partially reverts rust-lang/rust#134006 (the separate workflow part, not the tidy extra checks component), but is not prejudice against relanding the `typos`-based spellcheck in another implementation that goes through the usual bootstrap CI workflow so that it does work with Homu. The `typos`-based spellcheck seems to have a good false-positive rate. Closes rust-lang/rust#144183. --- r? infra-ci
This updates the rust-version file to efd420c770bb179537c01063e98cb6990c439654.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: efd420c770bb179537c01063e98cb6990c439654 Filtered ref: d11dbbb This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.