Skip to content

Rollup of 8 pull requests #142535

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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 18 commits into from

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jun 15, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

bjorn3 and others added 18 commits June 3, 2025 10:04
And move passing it to the linker to the driver code.
This deduplicates some code between codegen backends and may in the
future allow adding extra metadata that is only known at link time.
…ork, r=workingjubilee,saethlin

Move metadata object generation for dylibs to the linker code

This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.

Prerequisite of rust-lang#96708.
Handle win32 separator for cygwin paths

This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters.

r? ```@mati865```

cc ```@jeremyd2019```

~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~

Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths.

UPDATE: Windows path prefix is handled.
…-live-dead-fix, r=oli-obk

Async drop - fix for StorageLive/StorageDead codegen for pinned future

Fixes: rust-lang#140429, Fixes: rust-lang#140531, Fixes: rust-lang#141761, Fixes: rust-lang#141409.

StorageLive/StorageDead codegen is corrected for pinned async drop future.
Apply ABI attributes on return types in `rustc_codegen_cranelift`

- The [x86-64 System V ABI standard](https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build) doesn't sign/zero-extend integer arguments or return types.
- But the de-facto standard as implemented by Clang and GCC is to sign/zero-extend arguments to 32 bits (but not return types).
- Additionally, Apple targets [sign/zero-extend both arguments and return values to 32 bits](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms#Pass-arguments-to-functions-correctly).
- However, the `rustc_target` ABI adjustment code currently [unconditionally extends both arguments and return values to 32 bits](https://github.com/rust-lang/rust/blame/e703dff8fe220b78195c53478e83fb2f68d8499c/compiler/rustc_target/src/callconv/x86_64.rs#L240) on all targets.
- This doesn't cause a miscompilation when compiling with LLVM as LLVM will ignore the `signext`/`zeroext` attribute when applied to return types on non-Apple x86-64 targets.
- Cranelift, however, does not have a similar special case, requiring `rustc` to set the argument extension attribute correctly.
- However, `rustc_codegen_cranelift` doesn't currently apply ABI attributes to return types at all, meaning `rustc_codegen_cranelift` will currently miscompile `i8`/`u8`/`i16`/`u16` returns on x86-64 Apple targets as those targets require sign/zero-extension of return types.

This PR fixes the bug(s) by making the `rustc_target` x86-64 System V ABI only mark return types as sign/zero-extended on Apple platforms, while also making `rustc_codegen_cranelift` apply ABI attributes to return types. The RISC-V and s390x C ABIs also require sign/zero extension of return types, so this will fix those targets when building with `rustc_codegen_cranelift` too.

r? ```@bjorn3```
Add `f16` inline asm support for LoongArch

r? ```@Amanieu```
bump std libc dependency

Bump libc, it contains prerequisites for a rust-lang#140867 fix
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 15, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 15, 2025

📌 Commit bf2794a has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 15, 2025
@bors
Copy link
Collaborator

bors commented Jun 15, 2025

⌛ Testing commit bf2794a with merge 8d94b0d...

bors added a commit that referenced this pull request Jun 15, 2025
Rollup of 8 pull requests

Successful merges:

 - #133952 (Remove wasm legacy abi)
 - #141769 (Move metadata object generation for dylibs to the linker code )
 - #141864 (Handle win32 separator for cygwin paths)
 - #142347 (Async drop - fix for StorageLive/StorageDead codegen for pinned future)
 - #142389 (Apply ABI attributes on return types in `rustc_codegen_cranelift`)
 - #142470 (Add some missing mailmap entries)
 - #142481 (Add `f16` inline asm support for LoongArch)
 - #142509 (bump std libc dependency)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job dist-various-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling addr2line v0.25.0
[RUSTC-TIMING] addr2line test:false 0.665
[RUSTC-TIMING] gimli test:false 4.270
[RUSTC-TIMING] object test:false 5.779
error[E0560]: struct `timespec` has no field named `tv_nsec`
   --> library/std/src/sys/pal/unix/thread.rs:253:21
    |
253 |                     tv_nsec: nsecs,
    |                     ^^^^^^^ `timespec` does not have this field
    |
    = note: all struct fields are already assigned

error[E0609]: no field `tv_nsec` on type `timespec`
   --> library/std/src/sys/pal/unix/thread.rs:260:32
    |
260 |                     nsecs = ts.tv_nsec;
    |                                ^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
260 -                     nsecs = ts.tv_nsec;
260 +                     nsecs = ts.tv_sec;
    |

error[E0560]: struct `timespec` has no field named `tv_nsec`
  --> library/std/src/sys/pal/unix/time.rs:10:51
   |
10 |     libc::timespec { tv_sec: <libc::time_t>::MAX, tv_nsec: 1_000_000_000 - 1 };
   |                                                   ^^^^^^^ `timespec` does not have this field
   |
   = note: all struct fields are already assigned

error[E0609]: no field `tv_nsec` on type `timespec`
   --> library/std/src/sys/pal/unix/time.rs:133:42
    |
133 |         Timespec::new(t.tv_sec as i64, t.tv_nsec as i64).unwrap()
    |                                          ^^^^^^^ unknown field
    |
help: a field with a similar name exists
    |
133 -         Timespec::new(t.tv_sec as i64, t.tv_nsec as i64).unwrap()
133 +         Timespec::new(t.tv_sec as i64, t.tv_sec as i64).unwrap()
    |

error[E0560]: struct `timespec` has no field named `tv_nsec`
   --> library/std/src/sys/pal/unix/time.rs:201:13
    |
201 |             tv_nsec: self.tv_nsec.as_inner().try_into().ok()?,
    |             ^^^^^^^ `timespec` does not have this field
    |
    = note: all struct fields are already assigned

error[E0560]: struct `timespec` has no field named `tv_nsec`
    --> library/std/src/sys/fs/unix.rs:1507:52
     |
1507 |             None => Ok(libc::timespec { tv_sec: 0, tv_nsec: libc::UTIME_OMIT as _ }),
     |                                                    ^^^^^^^ `timespec` does not have this field
     |
     = note: all struct fields are already assigned

Some errors have detailed explanations: E0560, E0609.
For more information about an error, try `rustc --explain E0560`.

@bors
Copy link
Collaborator

bors commented Jun 15, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 15, 2025
@fmease
Copy link
Member

fmease commented Jun 15, 2025

@fmease fmease closed this Jun 15, 2025
@tgross35 tgross35 mentioned this pull request Jun 16, 2025
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.