r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

@rustbot author

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

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

The commit I need - rust-lang/libc@9934c04 is not yet tagged/released. Or rather there is a ctest-* tag but I suspect that doesn't apply/not intended use for that tag. Should I try to execute a tag/release of libc, or just wait for that to happen naturally?

This PR depends on a newer version of the libc crate - maybe I'll let this PR hang here for a bit and check back in when it gets released and promoted?

You need libc at 0.2.179, right? You can update libc here – but please keep it in a separate commit.

The commit I need - rust-lang/libc@9934c04 is not yet tagged/released. Or rather there is a ctest-* tag but I suspect that doesn't apply/not intended use for that tag. Should I try to execute a tag/release of libc, or just wait for that to happen naturally?

Ah - I see now that it appears in 0.2.181 and there's already a PR open for that (#150752). I'll rebase when that lands.

@rustbot ready

cc @quic-mliebel

gentle ping @joboet

LGTM once libc::stat and raw::stat match

LGTM once libc::stat and raw::stat match

Fixed

Looks like blkcnt_t and blksize_t are needed:

python3 x.py check library --target hexagon-unknown-qurt

...

error[E0432]: unresolved import `super::platform::raw::blkcnt_t`
  --> library/std/src/os/unix/raw.rs:30:32
   |
30 | pub use super::platform::raw::{blkcnt_t, time_t};
   |                                ^^^^^^^^ no `blkcnt_t` in `os::qurt::raw`
   |
   = help: consider importing this type alias instead:
           libc::blkcnt_t

error[E0432]: unresolved import `super::platform::raw::blksize_t`
  --> library/std/src/os/unix/raw.rs:33:32
   |
33 | pub use super::platform::raw::{blksize_t, dev_t, ino_t, mode_t, nlink_t, off_t};
   |                                ^^^^^^^^^ no `blksize_t` in `os::qurt::raw`
   |
   = help: consider importing this type alias instead:
           libc::blksize_t

Looks like blkcnt_t and blksize_t are needed:

python3 x.py check library --target hexagon-unknown-qurt

...

error[E0432]: unresolved import `super::platform::raw::blkcnt_t`
  --> library/std/src/os/unix/raw.rs:30:32
   |
30 | pub use super::platform::raw::{blkcnt_t, time_t};
   |                                ^^^^^^^^ no `blkcnt_t` in `os::qurt::raw`
   |
   = help: consider importing this type alias instead:
           libc::blkcnt_t

error[E0432]: unresolved import `super::platform::raw::blksize_t`
  --> library/std/src/os/unix/raw.rs:33:32
   |
33 | pub use super::platform::raw::{blksize_t, dev_t, ino_t, mode_t, nlink_t, off_t};
   |                                ^^^^^^^^^ no `blksize_t` in `os::qurt::raw`
   |
   = help: consider importing this type alias instead:
           libc::blksize_t

Fixed, thanks

ping @joboet

Sorry for the delay, I was taking a bit of a break from reviewing.

Could you provide a bit more context on QuRT? It looks like quite a lot of UNIX stuff is stubbed out here. How much UNIX-compatibility does QuRT actually provide? I'm asking because we have some similar UNIX-adjacent targets (e.g. Hermit, TEEOS) that don't list UNIX as their target family and instead just reuse the UNIX code in std where applicable.

@rustbot label +I-libs-nominated
I think this question has come up before, but how much UNIX-compatibility do you want to require for the UNIX target family?

Sorry for the delay, I was taking a bit of a break from reviewing.

Could you provide a bit more context on QuRT? It looks like quite a lot of UNIX stuff is stubbed out here. How much UNIX-compatibility does QuRT actually provide? I'm asking because we have some similar UNIX-adjacent targets (e.g. Hermit, TEEOS) that don't list UNIX as their target family and instead just reuse the UNIX code in std where applicable.

QuRT is a proprietary RTOS for Hexagon, ARM, RISC-V architectures that is usually focused on embedded DSP/uC devices without a direct storage device, without an interactive terminal/shell/UART. It has memory-protected processes, some POSIX capability like pthreads/mutexes. QuRT lacks SysV IPC. QuRT provides an indirect access to a filesystem via calls to some-other-SoC-node-with-a-disk.

But yeah - I'm totally fine w/redoing this PR to avoid touching UNIX and making it look more like hermit/teeos. Will take a look and update the PR.

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

These commits modify compiler targets.
(See the Target Tier Policy.)

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.