Raise libc's FreeBSD ABI to 12

[asomers]

FreeBSD 11 will be EoL on 30-Sept-2021. Update libc's ABI to the
minimum supported version of FreeBSD.

[rust-highfive]

r? @Amanieu

(rust-highfive has picked a reviewer for you, use r? to override)

[Amanieu]

LGTM, but cc @JohnTitor just in case.

[JohnTitor]

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.

[asomers]

rust PR: rust-lang/rust#89083 .

[bors]

☔ The latest upstream changes (presumably #2545) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnTitor]

Triage: I guess we should wait for rust-lang/rust#89058, and I wonder if we could release this along with the musl change.

[asomers]

@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?

[workingjubilee]

Tagging this as breakage-candidate on the same "should be included in the upcoming review" rationale.

[workingjubilee]

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.

[jrtc27]

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.

[workingjubilee]

• FCP: Drop support for FreeBSD 10 and 11 from std rust#89058
• Rust toolchain update: Update FreeBSD toolchain to 12.3 rust#97944

@asomers Please resolve the merge conflict.

[asomers]

Merge conflict resolved, @workingjubilee .

[workingjubilee]

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 #3139 is a better example of something we might want to wait for 0.3.0 before accepting. Might.

[JohnTitor]

Given rust-lang/rust#114521 has been merged and rust-lang/rust#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+

[bors]

📌 Commit d3f5a15 has been approved by JohnTitor

It is now in the queue for this repository.

[bors]

⌛ Testing commit d3f5a15 with merge 17cc521...

[JohnTitor]

@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.

[JohnTitor]

Maybe making a Rust inside blog post before releasing would be an alternative way to announce, I guess.

[bors]

☀️ Try build successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Build commit: 17cc521 (17cc5219ae6bb41ef2ff7d076c423a864e18de66)

[BlackHoleFox]

@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.