Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Broken MIR in async fn generation #73914

Closed
mtnmts opened this issue Jul 1, 2020 · 4 comments · Fixed by #73969
Closed

Broken MIR in async fn generation #73914

mtnmts opened this issue Jul 1, 2020 · 4 comments · Fixed by #73969
Assignees
Labels
A-async-await Area: Async & Await A-coroutines Area: Coroutines C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@mtnmts
Copy link

mtnmts commented Jul 1, 2020

Hey, This code attempts to increment a integer behind a tokio RwLock by 1, This causes a compiler error.

Minimized example that reproduces the ICE:

use tokio::sync::RwLock;
use std::io;

#[tokio::main]
async fn main() ->  io::Result<()> {
    State::default().crash_compiler().await; Ok(())
}

#[derive(Default)]
struct State {
    value: RwLock<u64>,
}

impl State {
    async fn crash_compiler(&mut self) {
        let i : u64 = 1;
        *self.value.write().await = *self.value.read().await + i;
    }
}

But, making this very small modification makes the code not break the compiler

...
        let v = *self.value.read().await + i;
        *self.value.write().await = v;
...

my Cargo.toml contains tokio = {version = "0.2.21", features=["full"] } as a dependency.

This code does not compile, and generates the following error (full backtrace in bottom of the issue)

   Compiling compiler_bug v0.1.0 (/home/martin/code/compiler_bug)
error: internal compiler error: src/librustc_mir/transform/generator.rs:715:13: Broken MIR: generator contains type (u64, bool) in MIR, but typeck only knows about for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}
  --> src/main.rs:15:40
   |
15 |       async fn crash_compiler(&mut self) {
   |  ________________________________________^
16 | |         let i : u64 = 1;
17 | |         *self.value.write().await = *self.value.read().await + i;
18 | |     }
   | |_____^

thread 'rustc' panicked at 'Box<Any>', /rustc/f455e46eae1a227d735091091144601b467e1565/src/libstd/macros.rs:13:23
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.46.0-nightly (f455e46ea 2020-06-20) running on x86_64-unknown-linux-gnu

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

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

error: aborting due to previous error

error: could not compile `compiler_bug`.

Meta

rustc --version --verbose

rustc 1.46.0-nightly (f455e46ea 2020-06-20)
binary: rustc
commit-hash: f455e46eae1a227d735091091144601b467e1565
commit-date: 2020-06-20
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0

also breaks the same way on stable (the traces attached are from nightly ^)

rustup run stable rustc --version -v

rustc 1.44.1 (c7087fe00 2020-06-17)
binary: rustc
commit-hash: c7087fe00d2ba919df1d813c040a5d47e43b0fe7
commit-date: 2020-06-17
host: x86_64-unknown-linux-gnu
release: 1.44.1
LLVM version: 9.0

Backtrace (RUST_BACKTRACE=1)

 Compiling compiler_bug v0.1.0 (/home/martin/code/compiler_bug)
error: internal compiler error: src/librustc_mir/transform/generator.rs:715:13: Broken MIR: generator contains type (u64, bool) in MIR, but typeck only knows about for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}
  --> src/main.rs:15:40
   |
15 |       async fn crash_compiler(&mut self) {
   |  ________________________________________^
16 | |         let i : u64 = 1;
17 | |         *self.value.write().await = *self.value.read().await + i;
18 | |     }
   | |_____^

thread 'rustc' panicked at 'Box<Any>', /rustc/f455e46eae1a227d735091091144601b467e1565/src/libstd/macros.rs:13:23
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: rustc_driver::report_ice
  11: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at /home/martin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc/boxed.rs:1090
  12: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}::{{closure}}
             at /home/martin/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libproc_macro/bridge/client.rs:318
  13: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
  14: std::panicking::begin_panic
  15: rustc_errors::HandlerInner::span_bug
  16: rustc_errors::Handler::span_bug
  17: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
  18: rustc_middle::ty::context::tls::with_opt::{{closure}}
  19: rustc_middle::ty::context::tls::with_opt
  20: rustc_middle::util::bug::opt_span_bug_fmt
  21: rustc_middle::util::bug::span_bug_fmt
  22: <rustc_mir::transform::generator::StateTransform as rustc_mir::transform::MirPass>::run_pass
  23: rustc_mir::transform::run_passes
  24: rustc_mir::transform::run_optimization_passes
  25: rustc_mir::transform::optimized_mir
  26: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::optimized_mir>::compute
  27: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  28: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  29: rustc_data_structures::stack::ensure_sufficient_stack
  30: rustc_query_system::query::plumbing::get_query_impl
  31: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  32: rustc_middle::ty::layout::layout_raw
  33: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::layout_raw>::compute
  34: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  35: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  36: rustc_data_structures::stack::ensure_sufficient_stack
  37: rustc_query_system::query::plumbing::get_query_impl
  38: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  39: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
  40: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  41: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
  42: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  43: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  44: rustc_middle::ty::layout::layout_raw
  45: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::layout_raw>::compute
  46: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  47: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  48: rustc_data_structures::stack::ensure_sufficient_stack
  49: rustc_query_system::query::plumbing::get_query_impl
  50: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  51: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
  52: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  53: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
  54: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  55: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  56: rustc_middle::ty::layout::layout_raw
  57: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::layout_raw>::compute
  58: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  59: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  60: rustc_data_structures::stack::ensure_sufficient_stack
  61: rustc_query_system::query::plumbing::get_query_impl
  62: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  63: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  64: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
  65: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  66: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  67: rustc_middle::ty::layout::layout_raw
  68: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::layout_raw>::compute
  69: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  70: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  71: rustc_data_structures::stack::ensure_sufficient_stack
  72: rustc_query_system::query::plumbing::get_query_impl
  73: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  74: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
  75: <core::iter::adapters::chain::Chain<A,B> as core::iter::traits::iterator::Iterator>::try_fold
  76: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  77: rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt>::layout_raw_uncached
  78: rustc_middle::ty::layout::layout_raw
  79: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::layout_raw>::compute
  80: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  81: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  82: rustc_data_structures::stack::ensure_sufficient_stack
  83: rustc_query_system::query::plumbing::get_query_impl
  84: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
  85: <rustc_mir::transform::const_prop::ConstPropagator as rustc_middle::mir::visit::MutVisitor>::visit_statement
  86: <rustc_mir::transform::const_prop::ConstPropagator as rustc_middle::mir::visit::MutVisitor>::visit_body
  87: <rustc_mir::transform::const_prop::ConstProp as rustc_mir::transform::MirPass>::run_pass
  88: rustc_mir::transform::run_passes
  89: rustc_mir::transform::run_optimization_passes
  90: rustc_mir::transform::optimized_mir
  91: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::optimized_mir>::compute
  92: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  93: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  94: rustc_data_structures::stack::ensure_sufficient_stack
  95: rustc_query_system::query::plumbing::get_query_impl
  96: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::instance_mir
  97: rustc_mir::monomorphize::collector::collect_neighbours
  98: rustc_data_structures::stack::ensure_sufficient_stack
  99: rustc_mir::monomorphize::collector::collect_items_rec
 100: rustc_mir::monomorphize::collector::collect_crate_mono_items
 101: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
 102: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::collect_and_partition_mono_items>::compute
 103: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
 104: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
 105: rustc_data_structures::stack::ensure_sufficient_stack
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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.46.0-nightly (f455e46ea 2020-06-20) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [optimized_mir] optimizing MIR for `State::crash_compiler::{{closure}}#0`
#1 [layout_raw] computing layout of `[static generator@src/main.rs:15:40: 18:6 self:&mut State for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}]`
#2 [layout_raw] computing layout of `std::future::from_generator::GenFuture<[static generator@src/main.rs:15:40: 18:6 self:&mut State for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}]>`
#3 [layout_raw] computing layout of `std::mem::ManuallyDrop<std::future::from_generator::GenFuture<[static generator@src/main.rs:15:40: 18:6 self:&mut State for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}]>>`
#4 [layout_raw] computing layout of `std::mem::MaybeUninit<std::future::from_generator::GenFuture<[static generator@src/main.rs:15:40: 18:6 self:&mut State for<'r, 's, 't0, 't1, 't2, 't3, 't4, 't5, 't6> {std::future::ResumeTy, &'r mut State, u64, State, &'s tokio::sync::rwlock::RwLock<u64>, tokio::sync::rwlock::RwLock<u64>, impl std::future::Future, (), &'t2 tokio::sync::rwlock::RwLockReadGuard<'t3, u64>, tokio::sync::rwlock::RwLockReadGuard<'t4, u64>, impl std::future::Future}]>>`
#5 [layout_raw] computing layout of `[static generator@src/main.rs:4:1: 4:15 for<'r, 's> {std::future::ResumeTy, &'r mut State, State, impl std::future::Future, ()}]`
#6 [optimized_mir] optimizing MIR for `main`
#7 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error

error: could not compile `compiler_bug`.
@jonas-schievink jonas-schievink added A-async-await Area: Async & Await A-coroutines Area: Coroutines E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jul 1, 2020
@mtnmts
Copy link
Author

mtnmts commented Jul 1, 2020

Confirmed this also breaks the same way on stable

@hellow554
Copy link
Contributor

hellow554 commented Jul 1, 2020

MCVE:

struct S<T>(std::marker::PhantomData<T>);

impl<T> std::ops::Deref for S<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        todo!()
    }   
}
impl<T> std::ops::DerefMut for S<T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        todo!()
    }   
}

async fn new() -> S<u64> {
    todo!()
}

async fn crash() {
    *new().await = 1 + 1;
}

fn main() {
    let _ = crash();
}

Fun fact: changing 1+1 to 2 doesn't ICE. Also I can't inline an S instance into the crash function. It has to be created outside?!. Weird stuff somtimes.

Also it would be nice to get rid of the deref, but I couldn't figure out how. So it's on this currently.

Also worth mentioning: this needs cargo build. check isn't sufficient.

@rustbot modify labels: -E-needs-mcve +E-needs-bisection

@rustbot rustbot added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc and removed E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example labels Jul 1, 2020
@hellow554
Copy link
Contributor

The bisection doesn't emit anything useful. This panics like forever. I went back to 2019-01-01 (with the old await! API and stuff) and it still ICEs there, so I guess it was like this forever.

Feel free to add the tag again, but I'll remove it.

@rustbot modify labels: -E-needs-bisection

@rustbot rustbot added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc and removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc labels Jul 1, 2020
@davidtwco davidtwco self-assigned this Jul 2, 2020
@bjorn3
Copy link
Member

bjorn3 commented Jul 3, 2020

@rustbot modify labels: -E-needs-bisection

@rustbot rustbot removed the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Jul 3, 2020
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 4, 2020
…mp-generator-interior, r=matthewjasper

mir: mark mir construction temporaries as internal

Fixes rust-lang#73914.

This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.

r? @matthewjasper
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 6, 2020
…mp-generator-interior, r=matthewjasper

mir: mark mir construction temporaries as internal

Fixes rust-lang#73914.

This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.

r? @matthewjasper
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 6, 2020
…mp-generator-interior, r=matthewjasper

mir: mark mir construction temporaries as internal

Fixes rust-lang#73914.

This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.

r? @matthewjasper
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 6, 2020
…mp-generator-interior, r=matthewjasper

mir: mark mir construction temporaries as internal

Fixes rust-lang#73914.

This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior.

r? @matthewjasper
@bors bors closed this as completed in 62ba1bf Jul 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-coroutines Area: Coroutines C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ 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.

6 participants