Expose the internal `SimpleMessage` struct and allow creating `std::io::Error`s with them

[dead-claudia]

Proposal

Problem statement

I'd like a way to define lightweight custom I/O errors that don't require allocation.

Motivation, use-cases

1. Offer a way forward for future better #![no_std] compatibility for std::io::Errors
2. Reduce generated code size for most common custom errors
3. Avoid needing to allocate memory for the common case with custom errors.

For some prior art and additional motivation:

• const_io_error! is already in broad use in std, with about 50 hits in a brief search: https://github.com/rust-lang/rust/search?q=const_io_error
• https://sourcegraph.com/search?q=context:global+/%5CbError::new%5C%28%5Cs*%28%28std::%29%3Fio::%29%3FErrorKind::%5Cw%2B%5Cs*%2C%5Cs*%22/+count:all+timeout:10s&patternType=standard&case=yes&sm=0&groupBy=repo yielded 33.7k results across over 3.8k repos searching just for the conservative case-sensitive regexp \bError::new\(\s*((std::)?io::)?ErrorKind::\w+\s*,\s*", with 14.2k results across 2.1k repos being of kind Other: https://sourcegraph.com/search?q=context:global+/%5CbError::new%5C%28%5Cs*%28%28std::%29%3Fio::%29%3FErrorKind::Other%5Cs*%2C%5Cs*%22/+count:all+timeout:10s&patternType=standard&case=yes&sm=0&groupBy=repo

Solution sketches

1. Expose the internal SimpleMessage struct as a way to provide lightweight errors along with an impl From<&'static SimpleMessage> for Error.
2. Expose const_io_error! to simplify construction of SimpleMessage-based errors, and default its $kind to ErrorKind::Other if not given.

Links and related work

• std::error::Error -> core::error::Error Tracking Issue for Error in core rust#103765 + Move Error trait into core rust#99917

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting. We were in favor of adding the macro for this, and not stabilizing SimpleMessage (since the macro can use internal unstable). We'd like to call the macro std::io::const_error!, so that people who already have use std::io can conveniently use io::const_error!(...).

[dead-claudia]

@joshtriplett Is there a tracking issue or PR I can follow?