-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Closed
Labels
A-HIRArea: The high-level intermediate representation (HIR)Area: The high-level intermediate representation (HIR)I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
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?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-HIRArea: The high-level intermediate representation (HIR)Area: The high-level intermediate representation (HIR)I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.