-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
ICE: no name for expr || #67252
Copy link
Copy link
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.
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.
Type
Fields
Give feedbackNo fields configured for issues without a type.
I wanted to quickly prototype a bit of code involving tokio and some shared state but ran into a rustc panic:
I installed
rustc 1.41.0-nightly (27d6f55f4 2019-12-11) running on x86_64-unknown-linux-gnuby 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) :
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?