Rollup of 7 pull requests #142616
Closed
Rollup of 7 pull requests #142616
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
In a PR to emit warnings on misuse of `--print native-static-libs`, we did not consider the matter of composing parts of build systems. If you are not directly invoking rustc, it can be difficult to know when you will in fact compile a staticlib, so making sure everyone uses `--print native-static-lib` correctly can be just a nuisance. This reverts the following commits: - f66787a - 72a9219 - 98bb597 - c59b708 Next cycle we can reland a slightly more narrowly focused variant or one that focuses on `--emit` instead of `--print native-static-libs`. But in its current state, I am not sure the warning is very useful.
This minimizes the chance of two PRs changing it from N to N+1.
Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: rust-lang#138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602) r? `@bjorn3` cc `@jieyouxu`
Update books ## rust-lang/book 1 commits in 634724ea85ebb08a542970bf8871ac8b0f77fd15..4433c9f0cad8460bee05ede040587f8a1fa3f1de 2025-06-03 16:34:00 UTC to 2025-06-03 16:34:00 UTC - Chapter 11 from tech review (rust-lang/book#4391) ## rust-lang/reference 10 commits in 8e0f593a30f3b56ddb0908fb7ab9249974e08738..d4c66b346f4b72d29e70390a3fa3ea7d4e064db1 2025-06-13 17:05:11 UTC to 2025-06-03 21:28:42 UTC - Align pattern destructuring with rest of patterns documentation (rust-lang/reference#1853) - Use extern "system" instead of "stdcall" in example (rust-lang/reference#1854) - Mention that `thiscall` is a 32-bit calling convention (rust-lang/reference#1855) - Add doc for keylocker target features (rust-lang/reference#1829) - Add doc for `sha512`, `sm3` and `sm4` target features (rust-lang/reference#1830) - Fix(typo): 'though' should be 'through' (rust-lang/reference#1850) - intro note: make text more simple (rust-lang/reference#1844) - nit: add missing period (rust-lang/reference#1843) - add a warning about using `safe` on extern c-variadic functions (rust-lang/reference#1839) - remove the `safe` keyword from a c-variadic foreign function. (rust-lang/reference#1838) ## rust-lang/rust-by-example 3 commits in 21f4e32b8b40d36453fae16ec07ad4b857c445b6..9baa9e863116cb9524a177d5a5c475baac18928a 2025-06-11 13:00:27 UTC to 2025-06-10 12:43:14 UTC - introduce new ````@media```` query to set a higher content width on ultra wide screens (rust-lang/rust-by-example#1937) - Fix syntax highligting (rust-lang/rust-by-example#1935) - fix(rust-lang#1656): update doc tests to use `playground` as the crate name (rust-lang/rust-by-example#1934)
…t-field-def, r=fmease
Fold unnecessary `visit_struct_field_def` in AstValidator
We don't need it anymore since we removed the `_: struct { }` syntax experiment.
…lds, r=jieyouxu Make sure to propagate result from `visit_expr_fields` We weren't propagating the `ControlFlow::Break` out of a struct field, which means that the solution implemented in rust-lang#130443 didn't work for nested fields. Fixes rust-lang#142525.
…39, r=ChrisDenton Revert overeager warning for misuse of `--print native-static-libs` In a PR to emit warnings on misuse of `--print native-static-libs`, we did not consider the matter of composing parts of build systems. If you are not directly invoking rustc, it can be difficult to know when you will in fact compile a staticlib, so making sure uses `--print native-static-lib` correctly can be just a nuisance. Next cycle we can reland a slightly more narrowly focused variant or one that focuses on `--emit` instead of `--print native-static-libs`. But in its current state, I am not sure the warning is very useful.
…workingjubilee Set elf e_flags on ppc64 targets according to abi (This PR contains the non user-facing changes of rust-lang#142321) Fixes rust-lang#85589 by making sure that ld.lld errors out instead of generating a broken binary. Basically the problem is that ld.lld assumes that all ppc64 object files with e_flags=0 are object files which use the ELFv2 ABI (this here is the check https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/PPC64.cpp#L639). This pull request sets the correct e_flags to indicate the used ABI so ld.lld errors out when encountering ELFv1 ABI files instead of generating a broken binary. For example compare code generation for this program (file name ``min.rs``): ```rust #![feature(no_core, lang_items, repr_simd)] #![crate_type = "bin"] #![no_core] #![no_main] #[lang = "sized"] trait Sized {} #[lang = "copy"] trait Copy {} #[lang = "panic_cannot_unwind"] pub fn panic() -> ! { loop {} } pub fn my_rad_unmangled_function() { loop {} } pub fn my_rad_function() { loop {} } #[no_mangle] pub fn _start() { my_rad_unmangled_function(); my_rad_function(); } ``` Compile with ``rustc --target=powerpc64-unknown-linux-gnu -C linker=ld.lld -C relocation-model=static min.rs`` Before change: ``` $ llvm-objdump -d min Disassembly of section .text: 000000001001030c <.text>: ... 10010334: 7c 08 02 a6 mflr 0 10010338: f8 21 ff 91 stdu 1, -112(1) 1001033c: f8 01 00 80 std 0, 128(1) 10010340: 48 02 00 39 bl 0x10030378 <_ZN3min25my_rad_unmangled_function17h7471c49af58039f5E> 10010344: 60 00 00 00 nop 10010348: 48 02 00 49 bl 0x10030390 <_ZN3min15my_rad_function17h37112b8fd1008c9bE> 1001034c: 60 00 00 00 nop ... ``` The branch instructions ``bl 0x10030378`` and ``bl 0x10030390`` are jumping into the ``.opd`` section which is data. That is a broken binary (because fixing those branches is the task of the linker). After change: ``` error: linking with `ld.lld` failed: exit status: 1 | = note: "ld.lld" "/tmp/rustcNYKZCS/symbols.o" "<1 object files omitted>" "--as-needed" "-L" "/tmp/rustcNYKZCS/raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "<sysroot>/lib/rustlib/powerpc64-unknown-linux-gnu/lib" "-o" "min" "--gc-sections" "-z" "relro" "-z" "now" = note: some arguments are omitted. use `--verbose` to show all linker arguments = note: ld.lld: error: /tmp/rustcNYKZCS/symbols.o: ABI version 1 is not supported ``` Which is correct because ld.lld doesn't support ELFv1 ABI.
…, r=aDotInTheVoid Add a comment to `FORMAT_VERSION`. This minimizes the chance of two PRs changing it from N to N+1. Fixes rust-lang#94591. r? ```@aDotInTheVoid```
rustbot
added
A-LLVM
|
@bors rollup=never p=5 r+ |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jun 17, 2025
Rollup of 7 pull requests Successful merges: - #141061 (Change __rust_no_alloc_shim_is_unstable to be a function) - #142585 (Update books) - #142586 (Fold unnecessary `visit_struct_field_def` in AstValidator) - #142587 (Make sure to propagate result from `visit_expr_fields`) - #142595 (Revert overeager warning for misuse of `--print native-static-libs`) - #142598 (Set elf e_flags on ppc64 targets according to abi) - #142601 (Add a comment to `FORMAT_VERSION`.) 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 is a failure of the test changed in #142224 hmm. cc @joshtriplett |
|
@bors2 try jobs=x86_64-gnu-aux |
rust-bors bot
added a commit
that referenced
this pull request
Jun 17, 2025
Rollup of 7 pull requests Successful merges: - #141061 (Change __rust_no_alloc_shim_is_unstable to be a function) - #142585 (Update books) - #142586 (Fold unnecessary `visit_struct_field_def` in AstValidator) - #142587 (Make sure to propagate result from `visit_expr_fields`) - #142595 (Revert overeager warning for misuse of `--print native-static-libs`) - #142598 (Set elf e_flags on ppc64 targets according to abi) - #142601 (Add a comment to `FORMAT_VERSION`.) r? `@ghost` `@rustbot` modify labels: rollup <!-- homu-ignore:start --> [Create a similar rollup](https://bors.rust-lang.org/queue/rust?prs=141061,142585,142586,142587,142595,142598,142601) <!-- homu-ignore:end --> try-job: x86_64-gnu-aux
|
truly flaky, huh. |
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:
visit_struct_field_defin AstValidator #142586 (Fold unnecessaryvisit_struct_field_defin AstValidator)visit_expr_fields#142587 (Make sure to propagate result fromvisit_expr_fields)--print native-static-libs#142595 (Revert overeager warning for misuse of--print native-static-libs)FORMAT_VERSION. #142601 (Add a comment toFORMAT_VERSION.)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup