fuchsia: clean up module

[dybucc]

Description

This is a clean-up patch. Changes are concerned with the fuchsia module.

There were lacking definitions. There were records with the wrong alignment. There were types that don't exist upstream. This has been fixed. But there's more stuff to fix.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

Sources

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT releases.

---

• wchar_t is not different across architectures. No specific definition was found. Verifying the current definition was not possible.
• nlink_t is not different across architectures.
• blksize_t is not different across architectures.
• ssizet_t had a wrong definition. Other _t-terminated types had similar issues. Those will not be further repeated in this list.
• A number of types did not exist in the SDK. They exist in vendored libc implementations. These are not part of the SDK. They can be found in cs.opensource.google. This includes suffixed offset types. These are omitted from further mention.

sysroot/include/bits/alltypes.h

---

• stat had a mismatched definition.

  sysroot/include/bits/stat.h

• glob_t had a mismatched definition.

  sysroot/include/glob.h

---

• signal.h types often had a mismatched definition. This header file appears later on in this source list. They refer to different paths. They contain different definitions.
• Affected types include:
  • siginfo_t.
  • sigevent.
  • sigaction.
• There was trouble with constants. SIG_DFL and others are function pointers. They are cast to function pointers from integers. They are sometimes NULL. This is not allowed in Rust. I have wrapped them in Option. They are all None now. They should not all be None. Transmutation from a pointer without provenance to a function pointer is required. This causes compile-time errors.

sysroot/include/signal.h

---

• stat64 doesn't exist.
• ipc_perm doesn't exist.
• epoll_data doesn't exist. Deprecation lints here keep popping up. I've attempted to silence them. My attempts have been futile.
• epoll_event doesn't exist.
• ff_effect doesn't exist.
• termios2 doesn't exist.
• sysinfo doesn't exist.
• mq_attr doesn't exist.
• sockaddr_nl doesn't exist.
• RLIM_SAVED_MAX doesn't exist.
• RLIM_SAVED_CUR doesn't exist.
• RLIM_INFINITY doesn't exist.
• RLIMIT_RTTIME doesn't exist.
• RLIMIT_NLIMITS doesn't exist.

---

There were conditional checks against 32-bit targets. Rust does not support 32-bit Fuchsia targets. The Fuchsia project does not support 32-bit machine word targets.

---

There was an oddity with pthread.h types. They were defined with a single field. This field sometimes had size equivalent to the sum of upstream fields. This has been replaced with the real fields. This has also fixed some size and alignment mismatches.

This has required changes in macros. An attempt has been made to fit the POSIX definitions. This means expanding static initializers to { 0 }. The new type definitions get all their fields zeroed. Some are made into null pointers. Should they be made into Option::Nones? They are not function pointer fields.

sysroot/include/pthread.h

---

Macros needed fixing. Their definition did not return a value. But a value was returned upstream. Some types needed small fixes.

sysroot/include/sched.h

---

• m_context had a mismatched definition. Some modules didn't have a definition.
• u_context had a mismatched definition. Some modules didn't have a definition.

sysroot/include/bits/signal.h

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 label +stable-nominated

[dybucc]

CI actually passes. There seems to be an issue with a glob import that is not used, but this has not
been changed in the patch (it's not even part of it, for that matter.) For some reason, rebasing
onto main with dependabot updates has ended up with a warning across all of my open PRs due to
that one (now apparently unused) import.

[tgross35]

@rustbot blocked
@SnoozeThis wait 2 months -> remove label S-blocked, add label S-waiting-on-review

Like other deprecations, holding off until we can actually give the users an alternative.

[SnoozeThis]

(https://snoozeth.is/db3wDy9dFKA) I will wait until Wed, 19 Aug 2026 08:31:22 UTC and then add label S-waiting-on-review and remove label S-blocked.

@rustbot claim.

[dybucc]

There's some problems in Fuchsia. Each vendored libc implementation has a different implementation. Sometimes they can be unified. Other times it's not possible. An example of the latter is stat. It resolves to different padding fields.

Should I also expose cfgs for each libc implementation?

[dybucc]

@tgross35 The PR has been remade. It now cleans up the fuchsia module.

The description is hopefully clearer. The details of the changes are included there. There should be no need for additional cfgs. Fuchsia has sane defaults and no suffixed types whatsoever. This is only taking into consideration their downloadable SDK. Third party libc implementations they vendor have been ignored.

One deprecation causes CI to fail. Its uses are allowed. That seems insufficient.

Style checks for reasons unknown. The indentation is right. The diagnosed code does not fit the code in my branch. That's likely related to macro expansion issues.

@rustbot ready review

[tgross35]

There is a lot of orthogonal changes going on here. Could you split it into separate commits to make this more clear? Each section of the PR description could be its own commit, but at a minimum please be sure to separate things like non-functional cleanup and deprecations from anything that's a behavior change. All of this in the same PR is completely fine of course.

(Splitting changes that can stand on their own is good practice in general, see https://www.kernel.org/doc/html/v7.0/process/submitting-patches.html#separate-your-changes for some of the canonical guidelines. Any descriptions/links can also live in the commit messages, it's fine to say "see commit messages for details" in the top post.)

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT release

In case you haven't come across it, web sources are at https://cs.opensource.google/fuchsia/fuchsia.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

It's not required - T2 targets are only "guaranteed to build", which the "verify build" jobs do. We do test a handful of T2 targets, but that's out of convenience rather than requirement.

That said, of course testing everything is ideal. I'll ping the Fuschia maintainers after history gets split.

View changes since this review

[tgross35]

If you have a source for long double being f128, mind posting it at rust-lang/rust#140417? I would have assumed f64.

Also this comment says i128 but should be f128.

[rustbot]

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

[tgross35]

There's some problems in Fuchsia. Each vendored libc implementation has a different implementation. Sometimes they can be unified. Other times it's not possible. An example of the latter is stat. It resolves to different padding fields.

Should I also expose cfgs for each libc implementation?

Each fuchsia target should only support a single libc. I don't see that listed in https://doc.rust-lang.org/rustc/platform-support/fuchsia.html but perhaps it should be? You could probably open a r-l/r PR updating that if there is a straightforward answer, or an issue if there isn't.

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

[dybucc]

There is a lot of orthogonal changes going on here. Could you split it into separate commits to make this more clear? Each section of the PR description could be its own commit, but at a minimum please be sure to separate things like non-functional cleanup and deprecations from anything that's a behavior change. All of this in the same PR is completely fine of course.

(Splitting changes that can stand on their own is good practice in general, see https://www.kernel.org/doc/html/v7.0/process/submitting-patches.html#separate-your-changes for some of the canonical guidelines. Any descriptions/links can also live in the commit messages, it's fine to say "see commit messages for details" in the top post.)

Paths are relative to the downloadable SDK. Look under the obj directory. Changes have been made relative to all NEXT release

In case you haven't come across it, web sources are at https://cs.opensource.google/fuchsia/fuchsia.

Testing is pending. This time testing is required. Two supported Fuchsia targets are tier 2. There's no CI job for them.

It's not required - T2 targets are only "guaranteed to build", which the "verify build" jobs do. We do test a handful of T2 targets, but that's out of convenience rather than requirement.

That said, of course testing everything is ideal. I'll ping the Fuschia maintainers after history gets split.

View changes since this review

I did come across the source browser. That's were I got confused by the vendored libc implementations. The SDK provides a single set of headers. This makes searches more "coherent."

The testing part was not meant for others. It was a personal reminder. But I understood the testing policy wrong. Just reread "Platform Support" in the rustc book. Thanks.