Skip to content

ICE for closure / proc confusion #13599

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.

Sign up for GitHub

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

Jump to bottom
Closed
wackywendell opened this issue Apr 18, 2014 · 0 comments · Fixed by #13657
Closed

ICE for closure / proc confusion #13599

wackywendell opened this issue Apr 18, 2014 · 0 comments · Fixed by #13657
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@wackywendell
Copy link
Contributor

Here is a minimal program:

fn main() {
    let nums = range(0,20);
    let tasks = nums.map(proc(n) {n * 2});
}

The map function takes a closure, not a proc, but attempting to compile this results in an internal compiler error instead of a nice error message:

% rustc fail-minimal.rs                                                                                   :(
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'assertion failed: `(left == right) && (right == left)` (left: `many`, right: `once`)', /build/rust-git/src/rust/src/librustc/util/ppaux.rs:288
stack backtrace:
   1:     0x7f097a174840 - rt::backtrace::imp::write::h225c71396cf30389qRa::v0.11.pre
   2:     0x7f097a0d6080 - rt::unwind::begin_unwind_inner::hf394975089b9a10eTra::v0.11.pre
   3:     0x7f097a0d5d00 - rt::unwind::begin_unwind_fmt::h22fcbc95e0e545013qa::v0.11.pre
   4:     0x7f097adbfdc0 - util::ppaux::ty_to_str::hb592748f8815eef7Kqh::v0.11.pre
   5:     0x7f097b034bf0 - middle::typeck::infer::InferCtxt$LT$$x27a$GT$::type_error_message::hffb9b35c27d4e338a3o::v0.11.pre
   6:     0x7f097b034dd0 - middle::typeck::infer::InferCtxt$LT$$x27a$GT$::report_mismatched_types::h45758484dd0f6fe8h4o::v0.11.pre
   7:     0x7f097affc5f0 - middle::typeck::check::demand::coerce::hd054c5403efa6f47b64::v0.11.pre
   8:     0x7f097b03ede0 - <unknown>
   9:     0x7f097b035740 - <unknown>
  10:     0x7f097b03f500 - <unknown>
  11:     0x7f097b03f0d0 - <unknown>
  12:     0x7f097b035740 - <unknown>
  13:     0x7f097b051820 - middle::typeck::check::check_decl_local::h81452c953e041c17Zzb::v0.11.pre
  14:     0x7f097b051aa0 - middle::typeck::check::check_stmt::h65a68c6329bac3deVBb::v0.11.pre
  15:     0x7f097b018040 - middle::typeck::check::check_block_with_expected::hf05f59868eb31121SFb::v0.11.pre
  16:     0x7f097b013730 - <unknown>
  17:     0x7f097b0134d0 - <unknown>
  18:     0x7f097b00e830 - middle::typeck::check::check_item::h7712d586a1e77a108w7::v0.11.pre
  19:     0x7f097b0133b0 - middle::typeck::check::check_item_types::hb0c38d033c99a851Ae7::v0.11.pre
  20:     0x7f097b153720 - <unknown>
  21:     0x7f097b152100 - middle::typeck::check_crate::h518ccce325ef460746t::v0.11.pre
  22:     0x7f097b591aa0 - driver::driver::phase_3_run_analysis_passes::h23bc51a4fd4272a46qe::v0.11.pre
  23:     0x7f097b5984b0 - driver::driver::compile_input::heeaf2ac59f6fbbc71Pe::v0.11.pre
  24:     0x7f097b5bc9a0 - run_compiler::h81631b1befd18d82lom::v0.11.pre
  25:     0x7f097b5d40a0 - <unknown>
  26:     0x7f097b5d29d0 - <unknown>
  27:     0x7f097b5ce2b0 - <unknown>
  28:     0x7f097a803b00 - <unknown>
  29:     0x7f097a16f870 - <unknown>
  30:     0x7f097a17b430 - rust_try
  31:     0x7f097a16f6b0 - rt::task::Task::run::h19b19c7dd158dbfefi8::v0.11.pre
  32:     0x7f097a8038d0 - <unknown>
  33:     0x7f097a173380 - <unknown>
  34:     0x7f09779abfe0 - start_thread
  35:     0x7f0979daace9 - clone
  36:                0x0 - <unknown>

This looks superficially similar to #8516 and #9400, but AFAICT they aren't the same.
@alexcrichton alexcrichton mentioned this issue Apr 21, 2014
Closed
@edwardw edwardw mentioned this issue Apr 21, 2014
Merged
edwardw added a commit to edwardw/rust that referenced this issue Apr 22, 2014
@edwardw
Fix ICE when reporting closure and proc mismatch
741142e 
Closes rust-lang#13599
bors added a commit that referenced this issue Apr 22, 2014
@bors
auto merge of #13657 : edwardw/rust/ppaux-ice, r=alexcrichton
92f6b92 
Closes #13599
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 7, 2024
@bors
Auto merge of rust-lang#13599 - RuairidhWilliamson:proc_macro_attr, r…
1bdc08a 
…=blyxyas

Fix allow_attributes when expanded from some macros

fixes rust-lang#13349

The issue here was that the start pattern being matched on the original source code was not specific enough. When using derive macros or in the issue case a `#[repr(C)]` the `#` would match the start pattern meaning that the expanded macro appeared to be unchanged and clippy would lint it.

The change I made was to make the matching more specific by matching `#[ident` at the start. We still need the second string to match just the ident on its own because of things like `#[cfg_attr(panic = "unwind", allow(unused))]`.

I also noticed some typos with start and end, these code paths weren't being reached so this doesn't fix anything.

changelog: FP: [`allow_attributes`]: don't trigger when expanded from some macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix ICE when reporting closure and proc mismatch edwardw/rust
2 participants
@alexcrichton @wackywendell