Automatic Rustup #4517
Closed
Automatic Rustup #4517
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
![workflows-miri[bot]](https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
add rdg push git config entry for git protocol pushers (again)
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: efd420c770bb179537c01063e98cb6990c439654 Filtered ref: d11dbbb02905535a89393e80c24274bee81fa928 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 2b5e239c6b86cde974b0ef0f8e23754fb08ff3c5 Filtered ref: dde2393b3444ae8595633863f4395f526b1b7932 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 32e7a4b92b109c24e9822c862a7c74436b50e564 Filtered ref: d39f3479bfafb04026ed3afec68aa671d13e9c3c This merge was created using https://github.com/rust-lang/josh-sync.
add a chapter documenting candidate preference
Rustc pull update
make toc generation fully automatic
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 383b9c447b61641e1f1a3850253944a897a60827 Filtered ref: 14b7b0bbd1e38402fca29ef84e5f75ee9d8cb1a9 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Consolidate staging for `rustc_private` tools This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap. The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers: - Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`) - Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc - Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice. `Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes. It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c1ed112c3dcfb5684b33772b136df0dca3. I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way. As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests. Since these changes broke Cargo, which was incorrectly using `Mode::ToolRustc`, I also changed cargo to `ToolTarget` in this PR. Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit). r? `@jieyouxu` try-job: x86_64-gnu-aux try-job: x86_64-msvc-ext1
Simplify dead code lint This PR scratches a few itches I had when looking at that code. The perf improvement comes from keeping the `scanned` set through several marking phases. This pretty much divides by 2 the number of HIR traversals.
Update installation.md
Update to LLVM 21 Timeline: LLVM 21.1.0 is scheduled to release on Aug 26th. Rust 1.90 branches on Aug 1st and releases September 18. Depends on: * [x] llvm/llvm-project#147781 * [x] llvm/llvm-project#147935 * [x] llvm/llvm-project#139443 * [x] llvm/llvm-project#148207 * [x] llvm/llvm-project#148607 * [x] llvm/llvm-project#149046 * [x] llvm/llvm-project#149097 * [x] rust-lang/rust#144116 r? `@ghost`
Add release notes for 1.89.0 r? `@BoxyUwU` cc `@rust-lang/release` `@rustbot` ping relnotes-interest-group
So we don't need to add normalization to every test that includes a panic message, add a global normalization to compiletest.
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
…iper
Print thread ID in panic message
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: dist-apple-various
try-job: dist-various-*
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: dist-x86_64-solaris
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-mingw-1
try-job: x86_64-msvc-1
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 6bcdcc73bd11568fd85f5a38b58e1eda054ad1cd Filtered ref: 6cc4ce79e1f8dc0ec5a2e18049b9c1a51dee3221 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
Revert "Preserve the .debug_gdb_scripts section" rust-lang/rust#143679 introduces a significant build time perf regression for ripgrep. Let's revert it such that we can investigate it without pressure.
Tweak auto trait errors
Make suggestions to remove params and super traits verbose and make spans more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
add nvptx_target_feature Tracking issue: #141468 (nvptx), which is part of #44839 (catch-all arches) The feature gate is `#![feature(nvptx_target_feature)]` This exposes the target features `sm_20` through `sm_120a` [as defined](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.1/llvm/lib/Target/NVPTX/NVPTX.td#L59-L85) by LLVM. Cc: ``````@gonzalobg`````` ``````@rustbot`````` label +O-NVPTX +A-target-feature
implement continue_ok and break_ok for ControlFlow Tracking issue: rust-lang/rust#140266 r? ``````@dtolnay``````
emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching This PR removes special handling of `let`-`else`, so that `StorageLive`s are emitted and `StorageDead`s are scheduled only after pattern-matching has succeeded. This means `StorageDead`s will no longer appear for all of its bindings on the `else` branch (because they're not live yet) and its drops&`StorageDead`s will happen together like they do elsewhere, rather than having all drops first, then all `StorageDead`s. This fixes rust-lang/rust#142056, and is therefore a breaking change. I believe it'll need a crater run and a T-lang nomination/fcp thereafter. Specifically, this makes drop-checking slightly more restrictive for `let`-`else` to match the behavior of other variable binding forms. An alternative approach could be to change the relative order of drops and `StorageDead`s for other binding forms to make drop-checking more permissive, but making that consistent would be a significantly more involved change. r? mir cc `````@dingxiangfei2009````` `````@rustbot````` label +T-lang +needs-crater
Mark all deprecation lints in name resolution as deny-by-default and report-in-deps This affects the next lints: - `MACRO_EXPANDED_MACRO_EXPORTS_ACCESSED_BY_ABSOLUTE_PATHS` - rust-lang/rust#144408 - `LEGACY_DERIVE_HELPERS` - rust-lang/rust#79202 - `PRIVATE_MACRO_USE` - rust-lang/rust#120192 - `OUT_OF_SCOPE_MACRO_CALLS` - rust-lang/rust#144406
Stabilize const TypeId::of fixes rust-lang/rust#77125 # Stabilization report for `const_type_id` ## General design ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? N/A the constness was never RFCed ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. `const_type_id` was kept unstable because we are currently unable to stabilize the `PartialEq` impl for it (in const contexts), so we feared people would transmute the type id to an integer and compare that integer. ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? `TypeId::eq` is not const at this time, and will only become const once const traits are stable. ## Has a Call for Testing period been conducted? If so, what feedback was received? This feature has been unstable for a long time, and most people just worked around it on stable by storing a pointer to `TypeId::of` and calling that at "runtime" (usually LLVM devirtualized the function pointer and inlined the call so there was no real performance difference). A lot of people seem to be using the `const_type_id` feature gate (600 results for the feature gate on github: https://github.com/search?q=%22%23%21%5Bfeature%28const_type_id%29%5D%22&type=code) We have had very little feedback except desire for stabilization being expressed. ## Implementation quality Until these three PRs * rust-lang/rust#142789 * rust-lang/rust#143696 * rust-lang/rust#143736 there was no difference between the const eval feature and the runtime feature except that we prevented you from using `TypeId::of` at compile-time. These three recent PRs have hardened the internals of `TypeId`: * it now contains an array of pointers instead of integers * these pointers at compile-time (and in miri) contain provenance that makes them unique and prevents inspection. Both miri and CTFE will in fact error if you mess with the bits or the provenance of the pointers in any way and then try to use the `TypeId` for an equality check. This also guards against creating values of type `TypeId` by any means other than `TypeId::of` ### Summarize the major parts of the implementation and provide links into the code (or to PRs) N/A see above ### Summarize existing test coverage of this feature Since we are not stabilizing any operations on `TypeId` except for creating `TypeId`s, the test coverage of the runtime implementation of `TypeId` covers all the interesting use cases not in the list below #### Hardening against transmutes * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id2.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id3.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id4.rs * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id5.rs #### TypeId::eq is still unstable * https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_cmp_type_id.rs ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? rust-lang/rust#129014 is still unresolved, but it affects more the runtime version of `TypeId` than the compile-time. ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? none ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization * `@eddyb` * `@RalfJung` ### Which tools need to be adjusted to support this feature. Has this work been done? N/A ## Type system and execution rules ### What compilation-time checks are done that are needed to prevent undefined behavior? Already covered above. Transmuting types with private fields to expose those fields has always been library UB, but for the specific case of `TypeId` CTFE and Miri will detect it if that is done in any way other than for reconstructing the exact same `TypeId` in another location. ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? N/A ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) N/A ### What updates are needed to the reference/specification? (link to PRs when they exist) Nothing more than what needs to exist for `TypeId` already. ## Common interactions ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? N/A ### What other unstable features may be exposed by this feature? N/A
… r=petrochenkov Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error. Per rust-lang/rust#79813 (comment)
Introduce ModernIdent type to unify macro 2.0 hygiene handling This pr introduce ModernIdent type to unify macro 2.0 hygiene handling 1. Added ModernIdent type. Wraps Ident and automatically calls `normalize_to_macros_2_0()` 2. Unified identifier normalization. Replaced scattered ident.normalize_to_macros_2_0() calls with ModernIdent::new(ident) r? ````@petrochenkov````
…acrum Address libunwind.a inconsistency issues in the bootstrap program We noticed when building rustc multiple time in a roll, some files will not be consistent across the build despite the fact that they are built from same source under the same environment. This patch addresses the inconsistency issue we found on libunwind.a, by sorting the order of the files passed to the linker.
…taxes, r=petrochenkov Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes` Workaround for rust-lang/rust#144588 (comment) Not all suggestions have to be hidden from `cargo fix`, only redundant ones. The redundant ones are already hidden from the user, so the same `tool_only` flag can be used to hide them from `cargo fix`. This way `cargo fix` will be able to correctly apply the fixes, and will apply only the fix that the compiler visibly suggests to the user.
…n,tgross35 Additional tce tests r? `@oli-obk` Adds known-bug tests for LLVM emissions regarding indirect operands for TCE. Also includes a test, `indexer.rs`, referring to function_table behavior described by the RFC. Depends on rust-lang/rust#144232 Closes rust-lang/rust#144293
bootstrap: refactor mingw dist and fix gnullvm Fixes rust-lang/rust#144533 The first two commits are NFC and only clean up the code, paving the way for the third commit. That said, I think they are worthwhile even without that fix - reusing the same function for two different outcomes was confusing. The third commit is the fix for rust-lang/rust#144533, but due to the cross-compilation dance it requires a workaround to find the DLL since that logic really was meant only for Windows builders. That workaround is short-lived and will be removed as soon as gnullvm bootstraps itself.
Stabilize `strict_overflow_ops` Closes rust-lang/rust#118260
Update books ## rust-lang/book 5 commits in b2d1a0821e12a676b496d61891b8e3d374a8e832..3e9dc46aa563ca0c53ec826c41b05f10c5915925 2025-08-02 01:33:29 UTC to 2025-07-14 21:23:38 UTC - Appendix B and Appendix D from tech review (rust-lang/book#4466) - Chapter 21 from tech review (rust-lang/book#4464) - Chapter 20 from tech review (rust-lang/book#4460) - Chapter 19 from tech review (rust-lang/book#4446) - Chapter 18 from tech review (rust-lang/book#4445) ## rust-lang/reference 12 commits in 1f45bd41fa6c17b7c048ed6bfe5f168c4311206a..1be151c051a082b542548c62cafbcb055fa8944f 2025-08-05 19:51:40 UTC to 2025-07-14 19:49:01 UTC - Fix build output directory in README (rust-lang/reference#1950) - Update `link_name` to use the attribute template (rust-lang/reference#1896) - Update `no_link` to use the attribute template (rust-lang/reference#1898) - Update `proc_macro_derive` to use the attribute template (rust-lang/reference#1888) - Update `automatically_derived` to use the attribute template (rust-lang/reference#1884) - Update `derive` to use the attribute template (rust-lang/reference#1883) - Fix and clarify CR LF normalization and CR in string literals (rust-lang/reference#1944) - glossary.md: tweak description of "dispatch" (rust-lang/reference#1938) - add missing id, r[asm.operand-type.supported-operands.const] (rust-lang/reference#1939) - &str and &[u8] have the same layout (rust-lang/reference#1848) - Rename and rewrite the "question mark operator" (rust-lang/reference#1931) - Change "allocated object" to "allocation". (rust-lang/reference#1930) ## rust-lang/rust-by-example 3 commits in e386be5f44af711854207c11fdd61bb576270b04..bd1279cdc9865bfff605e741fb76a0b2f07314a7 2025-08-04 13:41:04 UTC to 2025-08-02 15:41:59 UTC - Improve the activity instructions in `print_display` (rust-lang/rust-by-example#1948) - Minor fixes (whitespace, typo, i32->u32) (rust-lang/rust-by-example#1947) - Document drawbacks of alternatives to match binding (rust-lang/rust-by-example#1946)
Reimplement `print_region` in `type_name.rs`. Broken by rust-lang/rust#144776; this is reachable after all. Fixes rust-lang/rust#144994. The commit also adds a lot more cases to the `type-name-basic.rs`, because it's currently very anaemic. This includes some cases where region omission does very badly; these are marked with FIXME. r? `@fmease`
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@1beca63. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
bump bootstrap compiler to 1.90 beta There were significantly less `cfg(bootstrap)` and `cfg(not(bootstrap))` this release. Presumably due to the fact that we change the bootstrap stage orderings to reduce the need for them and it was successful 🙏
Rollup of 19 pull requests Successful merges: - rust-lang/rust#137831 (Tweak auto trait errors) - rust-lang/rust#138689 (add nvptx_target_feature) - rust-lang/rust#140267 (implement continue_ok and break_ok for ControlFlow) - rust-lang/rust#143028 (emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching) - rust-lang/rust#143764 (lower pattern bindings in the order they're written and base drop order on primary bindings' order) - rust-lang/rust#143808 (Port `#[should_panic]` to the new attribute parsing infrastructure ) - rust-lang/rust#143906 (Miri: non-deterministic floating point operations in `foreign_items`) - rust-lang/rust#143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps) - rust-lang/rust#144133 (Stabilize const TypeId::of) - rust-lang/rust#144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny) - rust-lang/rust#144439 (Introduce ModernIdent type to unify macro 2.0 hygiene handling) - rust-lang/rust#144473 (Address libunwind.a inconsistency issues in the bootstrap program) - rust-lang/rust#144601 (Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes`) - rust-lang/rust#144650 (Additional tce tests) - rust-lang/rust#144659 (bootstrap: refactor mingw dist and fix gnullvm) - rust-lang/rust#144682 (Stabilize `strict_overflow_ops`) - rust-lang/rust#145026 (Update books) - rust-lang/rust#145033 (Reimplement `print_region` in `type_name.rs`.) - rust-lang/rust#145040 (rustc-dev-guide subtree update) Failed merges: - rust-lang/rust#143857 (Port #[macro_export] to the new attribute parsing infrastructure) r? `@ghost` `@rustbot` modify labels: rollup
Clippy subtree update r? `@Manishearth` Cargo.lock update due to clippy version bump
Pass -Werror when building the LLVM wrapper cc rust-lang/rust#109712
This updates the rust-version file to a980cd4311ae4b5bf9099d418e32643d068f1344.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: a980cd4311ae4b5bf9099d418e32643d068f1344 Filtered ref: a5460b5 This merge was created using https://github.com/rust-lang/josh-sync.
|
Thank you for contributing to Miri! |
saethlin
force-pushed
the
rustup-2025-08-08
branch
from
ba0490d to
8025104
Compare
|
I see we have some normalization in |
|
Closing in favor of #4518. |
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.
Update
rustcto rust-lang/rust@a980cd4.