Possible try blocks regression in nightly

[AMDmi3]

Code

I tried this code (requires anyhow):

#![feature(try_blocks)]

fn main() {
    let _config: Result<String, anyhow::Error> = try {
        std::str::from_utf8(&std::fs::read("")?)?.to_string()
    };
}

If you prefer example without external dependencies

#![feature(try_blocks)]

struct Error {
}

impl From<std::io::Error> for Error {
    fn from(_: std::io::Error) -> Self {
        Self{}
    }
}

impl From<std::str::Utf8Error> for Error {
    fn from(_: std::str::Utf8Error) -> Self {
        Self{}
    }
}

fn main() {
    let _config: Result<String, Error> = try {
        std::str::from_utf8(&std::fs::read("")?)?.to_string()
    };
}

I expected to see this happen: successful compilation (which was the case up to (including) nighly-2025-11-14)

Instead, this happened: compilation failure

   Compiling anyhow v1.0.100
   Compiling dtmphaaYkobK v0.1.0 (/tmp/dtmphaaYkobK)
error[E0308]: mismatched types
   --> src/main.rs:5:30
    |
  5 |         std::str::from_utf8(&std::fs::read("")?)?.to_string()
    |                              ^^^^^^^^^^^^^^^^^^ expected `Result<String, Error>`, found `Result<_, Error>`
    |
    = note: `std::io::Error` and `anyhow::Error` have similar names, but are actually distinct types
note: `std::io::Error` is defined in crate `std`
   --> /rustc/b6d7ff3aa71e48e2901b0900f8b5d98126b537ed/library/std/src/io/error.rs:65:0
note: `anyhow::Error` is defined in crate `anyhow`
   --> /home/marakasov/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/anyhow-1.0.100/src/lib.rs:394:1
    |
394 | pub struct Error {
    | ^^^^^^^^^^^^^^^^
help: consider using `Result::expect` to unwrap the `Result<_, std::io::Error>` value, panicking if the value is a `Result::Err`
    |
  5 |         std::str::from_utf8(&std::fs::read("")?.expect("REASON"))?.to_string()
    |                                                +++++++++++++++++

For more information about this error, try `rustc --explain E0308`.
error: could not compile `dtmphaaYkobK` (bin "dtmphaaYkobK") due to 1 previous error

Version it worked on

It most recently worked on: rustc 1.93.0-nightly (2286e5d22 2025-11-13)

Version with regression

rustc --version --verbose:

rustc 1.93.0-nightly (b6d7ff3aa 2025-11-14)
binary: rustc
commit-hash: b6d7ff3aa71e48e2901b0900f8b5d98126b537ed
commit-date: 2025-11-14
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.5

[hanna-kruppe]

I believe this is an intended effect of #148725 — see rust-lang/rfcs#3721 for context

[jieyouxu]

(Note that changes to unstable features are not tracked as "regressions".)

[AMDmi3]

Right, it looks like intended breakage, and as per https://github.com/scottmcm/rfcs/blob/if-at-first-you-dont-succeed/text/3721-homogeneous-try-blocks.md#annotated-heterogeneous-try-blocks, restoring original heterogeneous behavior would be done as separate task. I guess this issue can be closed, it would just be nice to make note somewhere that there's +1 request for heterogeneous blocks support. For the record, my use case was grouping multiple errors with the same context, like this:

let config: anyhow::Result<Config> {                                                                                      
    toml::from_str::<Config>(std::str::from_utf8(&std::fs::read(&path)?)?)?
}
config.with_context(|| format!("cannot parse config file {}", path)?

[crumblingstatue]

My silly workaround for my projects using try and anyhow is to add an extension method to Result that converts it to an anyhow::Result: crumblingstatue/hexerator@72ef0df

However having to do this does lessen the appeal of try, so hopefully shortly after stabilization, there will be work on a heterogeneous version.