Skip to content

ICE: no name for expr ||  #67252

Closed
Closed
@trimoq

Description

@trimoq

I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic:

   Compiling actors v0.1.0 ([...]/actors)
error: internal compiler error: src/librustc/hir/map/mod.rs:1031: no name for expr ||

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:892:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.41.0-nightly (27d6f55f4 2019-12-11) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

I installed rustc 1.41.0-nightly (27d6f55f4 2019-12-11) running on x86_64-unknown-linux-gnu by running rustup update a few hours back.
In my code (see below) there seems to be a mistake, having a lock living too long i suppose.
The following code leads to the error (based on https://github.com/tokio-rs/tokio/blob/master/examples/echo.rs) :

#![warn(rust_2018_idioms)]

use tokio;
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use tokio::net::TcpListener;

use std::env;
use std::error::Error;

use std::sync::{Mutex, Arc};
use std::collections::HashMap;

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let addr = env::args().nth(1).unwrap_or("127.0.0.1:8080".to_string());

    let mut listener = TcpListener::bind(&addr).await?;
    println!("Listening on: {}", addr);
    
    let state: Arc<Mutex<HashMap<i32,i32>>> = Arc::new(Mutex::new(HashMap::new()));

    loop {
        let (mut socket, _) = listener.accept().await?;

        let handle = state.clone(); 
        tokio::spawn(async move {

            let mut buf = [0; 1024];

            loop {
                let n = socket
                    .read(&mut buf)
                    .await
                    .expect("failed to read data from socket");

                if n == 0 {
                    return;
                }

                // wanted to get another lock, this 
                let guard = handle.lock().unwrap();

                // if I remove this, ther is no error (compiler optimizing away most of the things?
                socket
                    .write_all(&buf[0..n])
                    .await
                    .expect("failed to write data to socket");
            }
        });
    }
}

Unfortunately I could not remove unnecessary parts of the code without making the panic go away.
Might this has something to do with detecting the lock lifetimes?

Metadata

Metadata

Assignees

Labels

A-HIRArea: The high-level intermediate representation (HIR)I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions