Closed
Description
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?