libc
libc copied to clipboard
rust-lang
Raise libc's FreeBSD ABI to 12
FreeBSD 11 will be EoL on 30-Sept-2021. Update libc's ABI to the minimum supported version of FreeBSD.
r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)
If rustc drops it, I think it's fine. Rustc's CI currently uses FreeBSD 11 (https://github.com/rust-lang/rust/blob/35c8f2612ffea42cc09350accdba934e85a19f35/src/ci/docker/scripts/freebsd-toolchain.sh#L8), could you ask infra folks if it's okay, and make a PR? When it's approved, I'll r+ this one.
:umbrella: The latest upstream changes (presumably #2545) made this pull request unmergeable. Please resolve the merge conflicts.
Triage: I guess we should wait for https://github.com/rust-lang/rust/issues/89058, and I wonder if we could release this along with the musl change.
@JohnTitor there is a possibility that this change could cause breakage downstream, for example if a downstream crate assumes something about the size of ino_t. Is there any way to use crater to check whether downstream crates will still compile?
Tagging this as breakage-candidate on the same "should be included in the upcoming review" rationale.
Also I hit up grep.app and searched for libc::ino_t, and I didn't find many users of it at all. Most of them were perfectly "by value" uses. The closest I can find is this thingie, "Reverie", which assumes that libc::ino_t will fit inside u32... and in that case, it's done via a direct cast rather than unsafe code.
Also, Reverie is Linux-only to begin with.
Is any progress happening on this? Given Rust's continued inflexibility regarding OS ABIs, this is blocking FreeBSD/riscv from having a working Rust toolchain.
- FCP: https://github.com/rust-lang/rust/issues/89058
- Rust toolchain update: https://github.com/rust-lang/rust/pull/97944
@asomers Please resolve the merge conflict.
My inclination is also to Just Merge This Already and have it go out in libc 0.2.{next}, with disregard to users (incorrectly) assuming things about the type of ino_t (hopefully they used the type alias fully knowing its value can differ from platform to platform?), but given the concern initially raised by @asomers, I started a conversation on Zulip to feel out if there's consensus or additional concerns.
Also after further reading the Reverie thing is a weird gdb thing that has its own definition and any resemblance to stat is in truth incidental, apparently?
I feel like https://github.com/rust-lang/libc/pull/3139 is a better example of something we might want to wait for 0.3.0 before accepting. Might.
Given https://github.com/rust-lang/rust/pull/114521 has been merged and https://github.com/rust-lang/rust/issues/89058 is now accepted, we can go ahead with this change. Removing FreeBSD 11 (and older) support should be announced somewhere (we may deprecate the modules first). @bors r+
:pushpin: Commit d3f5a156b6eb827d3fc6a78c10becf83b08e02a0 has been approved by JohnTitor
It is now in the queue for this repository.
:hourglass: Testing commit d3f5a156b6eb827d3fc6a78c10becf83b08e02a0 with merge 17cc5219ae6bb41ef2ff7d076c423a864e18de66...
@bors retry r- Ah, hm, I misunderstood this change. does this force users to use FreeBSD 12 unconditionally? Then I guess we have to make a period to announce the removal.
Maybe making a Rust inside blog post before releasing would be an alternative way to announce, I guess.
:sunny: Try build successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Build commit: 17cc5219ae6bb41ef2ff7d076c423a864e18de66 (17cc5219ae6bb41ef2ff7d076c423a864e18de66)
@JohnTitor A +1 from me at least on the blog post idea. It seemed to work fine for the Apple minimum bumps and I have yet to see anyone calling for my head for lack of notice.
