Skip to content

ICE: no name for expr || #67252

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
trimoq opened this issue Dec 12, 2019 · 7 comments · Fixed by #67289
Closed

ICE: no name for expr || #67252

trimoq opened this issue Dec 12, 2019 · 7 comments · Fixed by #67289
Assignees
Labels
A-HIR Area: The high-level intermediate representation (HIR) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@trimoq
Copy link

trimoq commented Dec 12, 2019

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?

@Centril Centril changed the title rustc panics with no name for expr || ICE: no name for expr || Dec 12, 2019
@Centril Centril added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-HIR Area: The high-level intermediate representation (HIR) E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example labels Dec 12, 2019
@Centril
Copy link
Contributor

Centril commented Dec 12, 2019

ICE occurs in:

_ => bug!("no name for {}", self.node_to_string(id))

@hellow554
Copy link
Contributor

hellow554 commented Dec 12, 2019

Error before:

error[E0391]: cycle detected when processing `main`
  --> src/main.rs:13:1
   |
13 | #[tokio::main]
   | ^^^^^^^^^^^^^^
   |
note: ...which requires processing `main::{{closure}}#0::{{closure}}#0`...
  --> src/main.rs:26:33
   |
26 |           tokio::spawn(async move {
   |  _________________________________^
27 | |
28 | |             let mut buf = [0; 1024];
29 | |
...  |
48 | |             }
49 | |         });
   | |_________^
   = note: ...which again requires processing `main`, completing the cycle
note: cycle used when processing `main::{{closure}}#0`
  --> src/main.rs:13:1
   |
13 | #[tokio::main]
   | ^^^^^^^^^^^^^^

Regression in 27d6f55

cc #65345 @davidtwco

(I'm on a MCVE)

@pnkfelix
Copy link
Member

triage: P-high, removing nomination tag.

@pnkfelix pnkfelix added P-high High priority and removed I-nominated labels Dec 12, 2019
@hellow554
Copy link
Contributor

hellow554 commented Dec 12, 2019

Here we go:

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};

fn spawn<T: Send>(_: T) {}
    
pub struct AFuture;
impl Future for AFuture{
    type Output = ();
    
    fn poll(mut self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<()> {
        unimplemented!()
    }
}

async fn foo() {
    spawn(async {
        let _a = std::ptr::null_mut::<()>(); // `*mut ()` is not `Send`
        AFuture.await;
    });
}

fn main() {}

So spawn takes a type that is Send, but *mut () isn't Send. That's causing the ICE.

@hellow554

This comment has been minimized.

@rustbot rustbot removed the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Dec 12, 2019
@hellow554
Copy link
Contributor

Not sure how to express the !Send for the MCVE here. You can of course use a new struct (like I did before with NoSend), or use a *mut _.
Interesting this works with Sync as well, but not with other (custom) traits. Maybe because Send is an auto trait?

@estebank
Copy link
Contributor

estebank commented Dec 13, 2019

Fixed output:

error: future cannot be sent between threads safely
  --> $DIR/unnamed-future.rs:18:5
   |
LL | fn spawn<T: Send>(_: T) {}
   |    -----    ---- required by this bound in `spawn`
...
LL |     spawn(async {
   |     ^^^^^ future is not `Send`
   |
   = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `*mut ()`
note: future is not `Send` as this value is used across an await
  --> $DIR/unnamed-future.rs:20:9
   |
LL |         let _a = std::ptr::null_mut::<()>(); // `*mut ()` is not `Send`
   |             -- has type `*mut ()`
LL |         AFuture.await;
   |         ^^^^^^^^^^^^^ await occurs here, with `_a` maybe used later
LL |     });
   |     - `_a` is later dropped here

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-HIR Area: The high-level intermediate representation (HIR) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants