Rust: [Nightly RustC -- Debug only] Type check fails in async functions when compiling to debug.

Created on 22 May 2020  路  4Comments  路  Source: rust-lang/rust

The rustc compiler panics for being unable to check the type of an object.
In the example, it's shown in the form of path.to_str() returning an Option, and File::open() being unable to take Option as a parameter type.

error[E0277]: the trait bound `std::option::Option<&str>: std::convert::AsRef<std::path::Path>` is not satisfied
   --> src/main.rs:7:28
    |
7   |     let mut f = File::open(path.to_str())?;
    |                            ^^^^^^^^^^^^^ the trait `std::convert::AsRef<std::path::Path>` is not implemented for `std::option::Option<&str>`
    |
   ::: /home/nitsuga/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/fs.rs:374:20
    |
374 |     pub fn open<P: AsRef<Path>>(path: P) -> io::Result<File> {
    |                    ----------- required by this bound in `std::fs::File::open`

This would be the expected compilation error for that snippet of code, but instead of that, the compiler just panics.

This error only occurs on asynchronous functions and in nightly.
It also only happens when not compiling with --release, only in debug.

Code

use std::fs::File;
use std::io::prelude::*;

// async_std or just calling an async function in any way possible will produce the same panic
// just here for example usage, as tokio is the most common async runtime.
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let path = std::path::Path::new(".");
    let mut f = File::open(path.to_str())?;
    let mut src = String::new();

    f.read_to_string(&mut src)?;

    Ok(())
}

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (d8878868c 2020-05-18)
binary: rustc
commit-hash: d8878868c8d7ef3779e7243953fc050cbb0e0565
commit-date: 2020-05-18
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 9.0

Error output

Backtrace

https://pastebin.com/6WaHRfij `RUST_BACKTRACE=1 cargo run --verbose`

A-incr-comp C-bug I-ICE P-high T-compiler regression-from-stable-to-nightly

Most helpful comment

@doctorn @nitsuga5124 oh, sorry, my bad, investigating.

All 4 comments

cc @csmoe (likely due to #71948 - suggest_await_before_try)

cc @csmoe (likely due to #71948 - suggest_await_before_try)

I can see why that could cause it.
I've also seen that #72426 could be caused due to a similar issue.
If it's the same issue, this issue should be kept as it provides a smaller example to reproduce and extra information in reproducing.

@doctorn @nitsuga5124 oh, sorry, my bad, investigating.

Kind of strange, this ice only triggered with -Cincremental, CARGO_INCREMENTAL=0 cargo b won't ice.

here is a mcve:

use std::fs::File;
use std::future::Future;
use std::io::prelude::*;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    block_on(async {
        {
            let path = std::path::Path::new(".");
            let mut f = File::open(path.to_str())?;
            //~^ ERROR the trait bound `std::option::Option<&str>: std::convert::AsRef<std::path::Path>` is not satisfied
            let mut src = String::new();
            f.read_to_string(&mut src)?;
            Ok(())
        }
    })
}

fn block_on<F>(f: F) -> Result<(), ()>
where
    F: Future<Output = Result<(), Box<dyn std::error::Error>>>,
{
    Ok(())
}

ICE: rustc --edition 2018 -Cincremental ice.rs
no-ICE: rustc --edition 2018 ice.rs

Was this page helpful?
0 / 5 - 0 ratings