Regression in nightly-2020-09-23: "missing as_flags in implementation" of OpenOptionsExt

[dtolnay]

The following code compiles fine with nightly-2020-09-22 (and stable rustc since 1.10.0) but not nightly-2020-09-23.

use std::os::unix::fs::OpenOptionsExt;

struct MyOpenOptions;

impl OpenOptionsExt for MyOpenOptions {
    fn mode(&mut self, _mode: u32) -> &mut Self {
        unimplemented!()
    }

    fn custom_flags(&mut self, _flags: i32) -> &mut Self {
        unimplemented!()
    }
}

error[E0046]: not all trait items implemented, missing: `as_flags`
 --> src/lib.rs:5:1
  |
5 | impl OpenOptionsExt for MyOpenOptions {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `as_flags` in implementation
  |
  = help: implement the missing item: `fn as_flags(&self) -> std::result::Result<i32, std::io::Error> { todo!() }`

This is minimized from https://github.com/async-rs/async-std/blob/e8126633a89aafea23259eb9faddb70b89f94423/src/fs/open_options.rs#L303-L313.

Mentioning #76110, #76801, @FedericoPonzi, @joshtriplett.

[jyn514]

Whoops, I didn't realize the trait itself was stable. Probably the PR should either be reverted or add a default implementation for as_flags().

[Stupremee]

Assigning P-critical as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[yoshuawuyts]

async-std is now broken on nightly as well: async-rs/async-std#883

[ollie27]

I was under the impression that the *Ext traits were not intended to be implemented outside of std which means this is really an issue with async-std which shouldn't have implemented OpenOptionsExt at all.

std::os::unix::process::CommandExt for example has had several methods added to it since 1.0. Is there something different with OpenOptionsExt or is this just that it was implemented by a popular crate?

[dtolnay]

The trait likely should have been sealed, but I think sealed traits were not invented until after 1.0.0.

[jonas-schievink]

Can we retroactively seal CommandExt? It seems like we should, if we keep adding methods like in #72160.

[jyn514]

Wouldn't that be a breaking change?

[jonas-schievink]

Yes, just like adding more methods to it (which has been done several times)

[joshtriplett]

We could do a crater run to see if sealing it would break anything.

[jyn514]

Well clearly it would - it would break async-std the same way as_flags() broke async std. We need to get them not to use OpenOptionsExt before we can change anything here.

[joshtriplett]

@jyn514 My comment was in reference to sealing CommandExt, not OpenOptionsExt.