I've created a tracking issue: #107460

Removing I-libs-api-nominated for now, until the attribute has documentation in the reference.

We discussed this once more in @rust-lang/lang, and confirmed that we have no objection to adding this on nightly.

@bors r+

We'd consider it a blocker for stabilization of read_buf that the attribute be either stabilized or at least documented in the reference or similar.

📌 Commit d7dac91 has been approved by joshtriplett

It is now in the queue for this repository.

I am concerned about this negatively affecting the experience of non-nightly users. For example with this code:

struct MyRead;
impl std::io::Read for MyRead {}

current stable gives you this error:

error[E0046]: not all trait items implemented, missing: `read`
 --> src/main.rs:3:1
 |
3 | impl std::io::Read for MyRead {}
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `read` in implementation
 |
 = help: implement the missing item: `fn read(&mut self, _: &mut [u8]) -> Result<usize, std::io::Error> { todo!() }`

whereas rustc built from this PR gives this error:

error[E0046]: not all trait items implemented, missing one of: `read`, `read_buf`
 --> src/main.rs:3:1
 |
3 | impl std::io::Read for MyRead {}
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing one of `read`, `read_buf` in implementation
 |
note: required because of this annotation
 --> /git/rust/library/std/src/io/mod.rs:552:1
 |
552 | #[rustc_must_implement_one_of(read, read_buf)]
 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Some concerns:

• I only know how to build rustc in dev mode. When it's built in stable mode, is it still going to tell the user to consider implementing the unstable read_buf method, which they cannot do on a stable toolchain? That would be undesirable and it would be good to have a UI test covering this case.

• Notice that even aside from "missing read" vs "missing one of read or read_buf", the new error is less helpful because it does not give you the signature you need to put, so there isn't a signature you can copy straight from the error into your code. Would it make sense to give 2 "help:", one with each signature?

• How does this impact rust-analyzer? When you write a trait impl and tell it to autofill the required methods, is it going to put both? neither? just the alphanumerically first one or the one on the lower line number in libstd? My sense is a lot of people rely on this autofill when writing trait impls in an IDE.

@bors r-

When it's built in stable mode, is it still going to tell the user to consider implementing the unstable read_buf method, which they cannot do on a stable toolchain? That would be undesirable and it would be good to have a UI test covering this case.

Valid; I agree that we should avoid suggesting implementing a method that you can't implement.

@WaffleLapkin, would that be feasible, and can you add a test verifying that behavior as well?

Notice that even aside from "missing read" vs "missing one of read or read_buf", the new error is less helpful because it does not give you the signature you need to put, so there isn't a signature you can copy straight from the error into your code. Would it make sense to give 2 "help:", one with each signature?

Fair. That seems like a reasonable solution for the common case.

How does this impact rust-analyzer? When you write a trait impl and tell it to autofill the required methods, is it going to put both? neither? just the alphanumerically first one or the one on the lower line number in libstd? My sense is a lot of people rely on this autofill when writing trait impls in an IDE.

@dtolnay thanks for rising these concerns! My guess is that r-a will not autofill any methods, as they all have default bodies. I'll look into how we can support this feature in r-a.

WaffleLapkin, would that be feasible, and can you add a test verifying that behavior as well?

@joshtriplett This should be feasible. I'll make a PR that removes mentions of unstable methods from this diagnostic and shows the signatures soonTM.

For now, marking this PR as blocked.

This should be feasible. I'll make a PR that removes mentions of unstable methods from this diagnostic and shows the signatures soon

@WaffleLapkin has there been any progress on this? thanks

@Dylan-DPC I made 0 progress on this so far. In my opinion r-a support is a bigger concern here (although I did not progress there either). I don't have much time to work on this recently :(

Also note that there were some concerns raised about read and read_buf having incompatible semantics, although I don't recall where exactly (maybe some tracking issue?), so I'm not sure if this can be supported at all.