espidf: fix stat

[MabezDev]

Marking as draft as currently dependant on a libc fix and release.

[rust-highfive]

r? @Mark-Simulacrum

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

[bors]

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

[Mark-Simulacrum]

@rustbot author

Please mark as waiting on review (e.g., with @rustbot ready) when this is ready for review.

[ivmarkov]

LGTM - I didn't notice that off_t is imported as off64_t on non-Linux platforms.

[MabezDev]

@rustbot ready

[gyscos]

Do we care about the horizon platform (Nintendo 3DS), which recently got similar changes to libc?
https://github.com/rust-lang/libc/pull/2714/files#diff-a828924ffbc30c564e49bc3652ffa5375a123671b228fc99b5775a29cff6eea5R33

Or, more generally, do we not want to prevent the definitions of libc (uid_t, gid_t, ...) and the ones here in std from deviating?

[ivmarkov]

Do we care about the horizon platform (Nintendo 3DS), which recently got similar changes to libc? https://github.com/rust-lang/libc/pull/2714/files#diff-a828924ffbc30c564e49bc3652ffa5375a123671b228fc99b5775a29cff6eea5R33

Or, more generally, do we not want to prevent the definitions of libc (uid_t, gid_t, ...) and the ones here in std from deviating?

I don't think there are "std" definitions of uid_t and gid_t. STD just uses u32 (or u16 on ESP-IDF and vxworks) for uid_t and gid_t. It is another topic whether it is not better to just use u32 everywhere - even on platforms where the uid_t and gid_t are 16 bit by downcasting u32 to u16 - just like e.g. the implementation of seek - which is also fixed - and where the i64 offset is downcasted to i32 for ESP-IDF.

With all that said, there is actually no notion of a "process" on the ESP-IDF so these APIs are not supposed to be called anyway. They should just be there so that STD compiles on ESP-IDF.

[Mark-Simulacrum]

Hm. I would have expected us to remove the Command APIs entirely for espidf, though historically we have not been extremely consistent on what to do for partially-supported std on various platforms.

Anyway, this PR seems ok to me.

@bors r+

[bors]

📌 Commit 4f6b3a6 has been approved by Mark-Simulacrum

[Dylan-DPC]

failed in rollup

@bors r-

[MabezDev]

So, off64_t isn't available on all platforms (inside libc), namely macos hence the failure in the rollup. I've added top-level imports that import off_t as off64_t using the same cfg logic that already exists for the other x64_t types.

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup=iffy

[bors]

📌 Commit 3569d43 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 3569d43 with merge 18f314e...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 18f314e to master...

[rust-timer]

Finished benchmarking commit (18f314e): comparison url.

Summary:

• Primary benchmarks: 🎉 relevant improvement found
• Secondary benchmarks: no relevant changes found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	0	1	0	1
mean2	N/A	N/A	-0.5%	N/A	-0.5%
max	N/A	N/A	-0.5%	N/A	-0.5%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩