net feature alone fails to compile in 1.1.5: sockopt uses crate::timespec, which net does not gate in

[darkhonor]

Enabling only net (with default-features = false) fails to compile. Both backends' sockopt modules reference crate::timespec unconditionally, but mod timespec is gated on a feature list that does not include net.

This affects consumers that opt into a minimal API surface rather than taking default features. In our case a crate depends on rustix purely for socket primitives and sets default-features = false, features = ["std", "net"] deliberately, so that the fs, process, thread and event APIs are not compiled in.

The configuration built cleanly on 1.1.4 and regressed in 1.1.5.

Reproduction

[dependencies]
rustix = { version = "=1.1.5", default-features = false, features = ["std", "net"] }

$ cargo build
error[E0433]: cannot find `timespec` in `crate`
   --> rustix-1.1.5/src/backend/linux_raw/net/sockopt.rs:293:39
    |
293 |                     .unwrap_or(crate::timespec::Secs::MAX),
    |                                       ^^^^^^^^ could not find `timespec` in the crate root
    |
note: found an item that was configured out
   --> rustix-1.1.5/src/lib.rs:410:5
    |
410 |   mod timespec;
    |       ^^^^^^^^
error: could not compile `rustix` (lib) due to 6 previous errors

Equivalently, from a checkout of v1.1.5:

$ cargo check --no-default-features --features std,net
6 x error[E0433]: cannot find `timespec` in `crate`

$ cargo check --no-default-features --features std,net,use-libc
3 x error[E0433]: cannot find `timespec` in `crate`

The error count differs by backend because backend/linux_raw/net/sockopt.rs has six references to crate::timespec and backend/libc/net/sockopt.rs has three.

Platform / versions

• rustix 1.1.5 (1.1.4 is unaffected)
• rustc 1.98.1, x86_64-unknown-linux-gnu; also reproduced on CI for aarch64-apple-darwin
• Both backends: linux_raw (default) and libc (use-libc)
• main at 287214b is the 1.1.5 release commit and carries the same gate, so the issue is present on main as well

Cause

src/lib.rs:389-409 gates the module:

#[cfg(any(
    feature = "fs",
    feature = "event",
    feature = "process",
    feature = "runtime",
    feature = "thread",
    feature = "time",
    ...
))]
mod timespec;

net is absent from that list, while SO_RCVTIMEO / SO_SNDTIMEO handling in both backends' sockopt.rs uses crate::timespec::Timespec and crate::timespec::Secs with no corresponding cfg.

Suggested fix

Add net to the gate, since the net API genuinely needs the module:

 #[cfg(any(
     feature = "fs",
     feature = "event",
+    feature = "net",
     feature = "process",
     feature = "runtime",
     feature = "thread",
     feature = "time",

src/timespec.rs depends only on core, crate::backend::c and crate::ffi, so this does not pull in any further feature-gated code.

With that one line applied to v1.1.5, the following all pass on rustc 1.98.1:

--no-default-features --features std,net              PASS  (was 6 errors)
--no-default-features --features std,net,use-libc     PASS  (was 3 errors)
--no-default-features --features std                  PASS
--no-default-features --features std,fs               PASS
--no-default-features --features all-apis             PASS
--no-default-features --features all-apis,use-libc    PASS

Gating the sockopt timeout code instead would also compile, but it would silently drop SO_RCVTIMEO / SO_SNDTIMEO support from a net-only build, which seems worse than compiling the module.

I am happy to open a PR with the one-line change if that is the preferred fix.

[darkhonor]

Closing as a duplicate. #1681 already proposes the identical one-line fix, opened 2026-09-17, and its checks are green. I searched existing issues before filing but not open pull requests, which is why I missed it.

Leaving the reproduction and verification matrix above in place for anyone who arrives here from a search; the change to merge is #1681.

[darkhonor]

Reopening. Closing this was the wrong call on my part.

#1681 carries the fix and predates this report, so credit for the change belongs there and I am not proposing a competing one. But the defect itself has no tracked report otherwise: #1681 is a pull request with no linked issue, and 1.1.5 is released and broken for anyone building with net and without default features. Leaving this open gives that a record with a reproduction, both backends' error counts, and the verification matrix, and something for the release to close against.

No action requested here beyond what #1681 already does.