`nightly-2025-10-12` adds a breaking change to `std::io::Error::description()`

[ADD-SP]

Steps to reproduce

I tried this code:

use std::error::Error;
use std::io::Error as IoError;
use std::io::ErrorKind as IoErrorKind;

#[expect(deprecated)]
fn desc(err: Box<dyn Error>) {
    eprintln!("{}", err.description());
}

fn main() {
    let io_err = IoError::new(IoErrorKind::Other, "an I/O error occurred");
    desc(Box::new(io_err));
}

I expected to both 1.90.0 and nightly-2025-10-12 prints "an I/O error occurred", but it didn't.

cargo +1.90.0 run
# > an I/O error occurred

cargo +nightly-2025-10-12 run
# > description() is deprecated; use Display

Root causes

This breaking change is introduced by #144373, and its motivation is:

Considering that description has been deprecated for over 5 years, it's reasonable to assume it is no longer used much and it's therefore acceptable to return a lower-quality error message. If anyone actually encounters this in practice then it would be additional motivation to update their outdated dependencies which still use description.

rust-lang/libs-team#615 (comment)

Not a strong enough motivation to me

This is because:

• It motivation is essentially “has been deprecated for over 5 years”, but it does not involve any actually issues encountered by downstream.
• Downstream is actually doing the string-comparison using std::io::Error::description().
• Changing the content of the returned &str is not a very VISIBLE warning for downstream. Without looking at the changelog of the next Rust stable release, the only chance for downstream to notice that is encountering the actual issue in testing or production.

It is surprising for me to see this kind of change in a non-major release.

Suggestions

Revert #144373.

[jieyouxu]

Triage notes: I will mark this as a regression-from-stable-to-beta for tracking purposes, even though technically from I understand from rust-lang/libs-team#615 (comment) this might be considered as an "intentional change". Libs or libs-api may or may not wish to consider this as "expected and acceptable" or consider mitigations/revert (in which case, a beta backport of the revert would be needed).

@rustbot label: +regression-from-stable-to-beta

[saethlin]

• Changing the content of the returned &str is not a very VISIBLE warning for downstream.

What would be a visible warning?

[ADD-SP]

• Changing the content of the returned &str is not a very VISIBLE warning for downstream.

What would be a visible warning?

Actually, I think it is hard to make a visible warning without breaking change in this case.

For me, visible warnings are similar to compile errors or lint warnings (except for deprecation warnings because downstream is using the #[allow(deprecated)]. However, compile errors might be too harsh, as they represent extremely severe breaking changes. A new lint also look not suitable for this case. This is the reason I suggest revert it.

[ChrisDenton]

Some history of std::error::Error::deprecated:

1.27: soft-deprecated (documented as deprecated but no warning)
1.42: deprecated (with a warning)
1.91: removed implementations from std

Rather than a full revert, another option is to just add back the std::io::Error description for custom messages.

[ChrisDenton]

Unfortunately this issue does not mention which crates are affected or provide real-world code but I did find a single use of it in tokio:

https://github.com/tokio-rs/tokio/blob/25a24de0e661d86fa059779e87e0605909465f4a/tokio/src/process/unix/pidfd_reaper.rs#L98-L109

#[allow(deprecated)]
fn is_rt_shutdown_err(err: &io::Error) -> bool {
    if let Some(inner) = err.get_ref() {
        // Using `Error::description()` is more efficient than `format!("{inner}")`,
        // so we use it here even if it is deprecated.
        err.kind() == io::ErrorKind::Other
            && inner.source().is_none()
            && inner.description() == RUNTIME_SHUTTING_DOWN_ERROR
    } else {
        false
    }
}

[luca3s]

Based on this URLO thread tokio has a workaround until they make a bigger change to use a custom enum.

[ChrisDenton]

Thanks! In which case, cc @Darksonn

[ADD-SP]

Based on this URLO thread tokio has a workaround until they make a bigger change to use a custom enum.

It looks like there is still a issue. Imagine the behavior change of std::io::Error::description has landed in Rust 1.91.0. And downstream compiles their application using Rust 1.91.0 and older tokio (<= 1.47.1), will this causes bugs?

If so, crates like tokio will have a bug that only exists in the Rust 1.91.0, but not in older Rust version, this might surprises the downstream.