GNU Hurd compilation failure: expected `SystemTime`, found `timespec`

[newpavlov]

Compiling project with cargo build -Z build-std=std --target=i686-unknown-hurd-gnu --features="std" causes the following compilation error:

error[E0308]: mismatched types
   --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/fs.rs:520:29
    |
520 |         Ok(SystemTime::from(self.stat.st_mtim))
    |            ---------------- ^^^^^^^^^^^^^^^^^ expected `SystemTime`, found `timespec`
    |            |
    |            arguments to this function are incorrect
    |
note: associated function defined here
   --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:585:8
    |
585 |     fn from(value: T) -> Self;
    |        ^^^^

error[E0308]: mismatched types
   --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/pal/unix/fs.rs:548:29
    |
548 |         Ok(SystemTime::from(self.stat.st_atim))
    |            ---------------- ^^^^^^^^^^^^^^^^^ expected `SystemTime`, found `timespec`
    |            |
    |            arguments to this function are incorrect
    |
note: associated function defined here
   --> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/convert/mod.rs:585:8
    |
585 |     fn from(value: T) -> Self;
    |        ^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `std` (lib) due to 2 previous errors
Error: Process completed with exit code 101.

See this CI job.

[bjorn3]

cc target maintainer @sthibaul

[sthibaul]

I guess horizon has the same issue?

This got broken by 408c0ea ("unix time module now return result") which dropped impl From<libc::timespec> for SystemTime

I guess the way forward is to make hurd use SystemTime::new(self.stat.st_atim.tv_sec as i64, self.stat.st_atim.tv_nsec as i64) instead.

I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?

[workingjubilee]

I guess horizon has the same issue?

...

I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?

Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.

[sthibaul]

I guess horizon has the same issue?
...
I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?

Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.

Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.

[sthibaul]

I guess horizon has the same issue?
...
I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?

Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.

Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.

(as in: getting the break notice from a getrandom CI build a dozen days after the merge does not look that robust)

[workingjubilee]

@sthibaul Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.

[sthibaul]

@sthibaul Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.

In Debian we will use the stable releases to compile all rust-needing Debian packages, as the Debian policy requires.

[workingjubilee]

$ git branch --contains 408c0ea2162b9892540a5b3916ddcac7713de8c3 | rg '(stable|master|beta)'
  beta
  master

The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?

[sthibaul]

The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?

Yes, please.