cleanup: Declare more padding fields as private Padding's

[3v1n0]

Description

We have more fields that are padding areas that are currently marked as
public and not marked as Padding, which is causing the generated Hash
and PartialEq implementations to take care of them wrongly.

So fix them

Sources

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[rustbot]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

Some changes occurred in OpenBSD module

cc @semarie

Some changes occurred in the Android module

cc @maurer

[tgross35]

For anything where the padding field is private, I'm happy to apply this change and get it into a release in the next day or two. Would you mind splitting these out to a separate commit or PR?

For everything where the field is public, we can do the change in main but can't release it (they really should be private unfortunately). libc is pretty strongly moving away from these traits so the better thing to do in these cases is to define the traits in nix (rather than deriving from libc) which is more content-aware and can make better decisions than libc.

[tgross35]

For anything where the padding field is private, I'm happy to apply this change and get it into a release in the next day or two. Would you mind splitting these out to a separate commit or PR?

For this you can feel free to include anything that is a tier 3 target since occasional breaking changes are fine. freebsd-riscv, openbsd, cygwin, haiku, hurd, csky, mips, riscv32, hexagon, uclibc, and newlib all fall into this category.

[3v1n0]

For anything where the padding field is private, I'm happy to apply this change and get it into a release in the next day or two. Would you mind splitting these out to a separate commit or PR?

Sure thing, let me play here to see the failures I can't replicate locally in CI first :)

[3v1n0]

@rustbot ready

[tgross35]

Sorry I forgot to get back to you here!

For this you can feel free to include anything that is a tier 3 target since occasional breaking changes are fine. freebsd-riscv, openbsd, cygwin, haiku, hurd, csky, mips, riscv32, hexagon, uclibc, and newlib all fall into this category.

Would you mind splitting the changes for these platforms to a separate PR? I'll backport those, since we can do these minor breaking changes to tier 3 targets. The rest can't be backported.

[tgross35]

(updating status)

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[JohnTitor]

@3v1n0 #4922 has been merged, could you fix conflicts?

[3v1n0]

@rustbot ready

@JohnTitor done

[JohnTitor]

Sorry for the delay, looks great so far. Could you squash commits into one?

[3v1n0]

Sorry for the delay, looks great so far. Could you squash commits into one?

I guess you can do during merge in github, however this looks to me a quite weird policy

[JohnTitor]

We do a rebase merge in the merge queue, and the change here is tiny and semantically has the same purpose, so squashign is preferred to me.

[rustbot]

Some changes occurred in an Android module

cc @maurer

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.