I/O safety breaks existing code

[sunfishcode]

As reported here, the I/O safety feature introduces a breaking change.

Reduced standalone testcase (playground link):

use std::os::unix::io::FromRawFd;
use std::fs::File;

pub fn create_fd<F: FromRawFd>() -> F {
    todo!()
}

fn main() {
    let _f = File::from(create_fd());
}

error[E0283]: type annotations needed
   --> src/main.rs:9:14
    |
9   |     let _f = File::from(create_fd());
    |              ^^^^^^^^^^ cannot infer type for type parameter `T` declared on the trait `From`
    |
    = note: cannot satisfy `File: From<_>`
note: required by `from`
   --> /.../lib/rustlib/src/rust/library/core/src/convert/mod.rs:371:5
    |
371 |     fn from(_: T) -> Self;
    |     ^^^^^^^^^^^^^^^^^^^^^^

It's possible to change the code to avoid the error, for example by changing the let _f = ... line to either of:

    let _f = create_fd::<File>();
    let _f: File = create_fd(); 

or, once I/O safety is stabilized, by changing create_fd to return OwnedFd instead of F: FromRawFd. The reporter also reported that they've already fixed their own code. Nevertheless, it is breakage observed in real-world code.

The problem is caused by I/O safety adding an impl From<OwnedFd> for File. We added these From impls as an alternative to adding a new FromFd trait. However, this means that File now has multiple From impls for types that implement AsRawFd, so one can no longer do File::from(create_fd()) where create_fd is defined like fn create_fd<F: FromRawFd>() -> F, because it's now ambiguous which type it should use for F.

So the questions here are:

• Is this breakage severe enough to block stabilization for I/O safety?
• If so, is there a way to fix it other than going back to adding a FromFd trait?

[scottmcm]

I think this is officially a "minor" change, and thus allowed -- it's like all the breakage that can happen when AsRef implementations are added. Assuming that's true, it's a libs judgment call on how bad the impact is in practice.

[cuviper]

This is about to ship in 1.56 -- cc @rust-lang/release

But AFAIK it didn't show problems in crater, so we'll probably let it go as a minor change...

[Mark-Simulacrum]

Certainly nothing significant, I think. Working with (raw) file descriptors is probably pretty rare, so I'm not expecting much breakage.

[sunfishcode]

1.56 has shipped now, and I haven't seen any other reports of breakage. So following the comments above, I'll close this issue now. If anyone does see any other instances of breakage, please report it!