Rollup of 16 pull requests #144942
Closed
Rollup of 16 pull requests #144942
+757
−461
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
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.
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.
Currently the Args new function is scope constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
Signed-off-by: Jonathan Brouwer <[email protected]>
The current `rust-version = "1.63"` was inherited from rayon, but it doesn't make sense to limit this in the compiler workspace. Having any setting at all has effects on tools like `cargo info` that try to infer the MSRV when the workspace itself doesn't specify it. Since we are the compiler, our only MSRV is whatever bootstrapping requires.
…zelmann Port #[macro_export] to the new attribute parsing infrastructure Ports macro_export to the new attribute parsing infrastructure for rust-lang#131229 (comment) r? ``@oli-obk`` cc ``@JonathanBrouwer`` ``@jdonszelmann``
…=lcnr Stabilize const TypeId::of fixes rust-lang#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#142789 * rust-lang#143696 * rust-lang#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#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
…-default, 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#79813 (comment)
…r-width, r=Noratrieb Make target pointer width in target json an integer r? Noratrieb cc ``@RalfJung`` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
…ark-Simulacrum 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.
…r=Kobzol bootstrap: refactor mingw dist and fix gnullvm Fixes rust-lang#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#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.
…k-Simulacrum Stabilize `strict_overflow_ops` Closes rust-lang#118260
…szelmann Port `#[coroutine]` to the new attribute system Related to rust-lang#131229 (comment). r? `@jdonszelmann`
Drop `rust-version` from `rustc_thread_pool` The current `rust-version = "1.63"` was inherited from rayon, but it doesn't make sense to limit this in the compiler workspace. Having any setting at all has effects on tools like `cargo info` that try to infer the MSRV when the workspace itself doesn't specify it. Since we are the compiler, our only MSRV is whatever bootstrapping requires.
…eyouxu [win][arm64ec] Fix msvc-wholearchive for Arm64EC `msvc-wholearchive` was failing on Arm64EC Windows as it requires the `/MACHINE:ARM64EC` flag to be passed to the MSVC linker. This required splitting the `extra_c_flags` function into a new `extra_linker_flags` function as `/MACHINE:ARM64EC` is not a valid argument to be passed to the MSVC Compiler (instead, `/arm64EC` should be used).
rustbot
added
A-attributes
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 5, 2025
Rollup of 16 pull requests Successful merges: - #143857 (Port #[macro_export] to the new attribute parsing infrastructure) - #144133 (Stabilize const TypeId::of) - #144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny) - #144443 (Make target pointer width in target json an integer) - #144473 (Address libunwind.a inconsistency issues in the bootstrap program) - #144659 (bootstrap: refactor mingw dist and fix gnullvm) - #144682 (Stabilize `strict_overflow_ops`) - #144794 (Port `#[coroutine]` to the new attribute system) - #144835 (Anonymize binders in tail call sig) - #144836 (Change visibility of Args new function) - #144900 (Stabilize `unsigned_signed_diff` feature) - #144903 (Rename `begin_panic_handler` to `panic_handler`) - #144910 (Add regression tests for seemingly fixed issues) - #144926 (Correct the use of `must_use` on btree::IterMut) - #144928 (Drop `rust-version` from `rustc_thread_pool`) - #144931 ([win][arm64ec] Fix msvc-wholearchive for Arm64EC) Failed merges: - #144914 (Add support for `ty::Instance` path shortening in diagnostics) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
This was referenced Aug 5, 2025
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.
Successful merges:
strict_overflow_ops#144682 (Stabilizestrict_overflow_ops)#[coroutine]to the new attribute system #144794 (Port#[coroutine]to the new attribute system)unsigned_signed_difffeature #144900 (Stabilizeunsigned_signed_difffeature)begin_panic_handlertopanic_handler#144903 (Renamebegin_panic_handlertopanic_handler)must_useon btree::IterMut #144926 (Correct the use ofmust_useon btree::IterMut)rust-versionfromrustc_thread_pool#144928 (Droprust-versionfromrustc_thread_pool)Failed merges:
ty::Instancepath shortening in diagnostics #144914 (Add support forty::Instancepath shortening in diagnostics)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup