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

ICE when trying to call Ord::cmp as a free function #18281

Closed
giogadi opened this issue Oct 24, 2014 · 1 comment
Closed

ICE when trying to call Ord::cmp as a free function #18281

giogadi opened this issue Oct 24, 2014 · 1 comment

Comments

@giogadi
Copy link

giogadi commented Oct 24, 2014

Here's the offending code:

use std::cmp::Ord;

fn main() {
    let x = 1i;
    let y = 2i;
    println!("{}", Ord::cmp(&x, &y));
}

rustc version info:

rustc 0.13.0-nightly (6ef8392b3 2014-10-20 22:17:49 +0000)
binary: rustc
commit-hash: 6ef8392b3fd5f81165f1b4637a94c7c226420070
commit-date: 2014-10-20 22:17:49 +0000
host: x86_64-apple-darwin
release: 0.13.0-nightly

and the stack trace:

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://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'assertion failed: `(left == right) && (right == left)` (left: `3`,     right: `0`)',     /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/librustc/middle/trans/callee.rs:528

stack backtrace:
   1:        0x10e5a93a9 - rt::backtrace::imp::write::hf323fec74faa7c8cmlq
   2:        0x10e5ac677 - failure::on_fail::h7143e6cb367a2e37VBq
   3:        0x10e806c15 - unwind::begin_unwind_inner::h38e7fe7d6aaf16401ud
   4:        0x10e8068dc - unwind::begin_unwind_fmt::hdf2ca956055cbb79tsd
   5:        0x10b5abab5 - middle::trans::callee::trans_fn_ref_with_substs::haa010be8569e1e4dLo3
   6:        0x10b5a8e61 - middle::trans::callee::trans_fn_ref::h0ffccf42044363afBc3
   7:        0x10b5b1e5b - middle::trans::callee::trans_call::closure.123047
   8:        0x10b58aab4 - middle::trans::callee::trans_call_inner::h765ee787cdb0c185vK3
   9:        0x10b5b1547 - middle::trans::callee::trans_call::he5f5f0bf10cb35cfPE3
  10:        0x10b5c1071 - middle::trans::expr::trans_rvalue_dps_unadjusted::he07ca709524b78858S5
  11:        0x10b5bf281 - middle::trans::expr::trans_unadjusted::h85d3b8a83dc2d19eEf5
  12:        0x10b584382 - middle::trans::expr::trans::ha3267407ca5ddba4Ay4
  13:        0x10b5ca548 - middle::trans::expr::trans_addr_of::h015af9fdde5130d6QG6
  14:        0x10b5bfa7f - middle::trans::expr::trans_unadjusted::h85d3b8a83dc2d19eEf5
  15:        0x10b582f09 - middle::trans::expr::trans_into::hf23cf72a72a546ffGu4
  16:        0x10b5d39e1 - middle::trans::expr::trans_adt::h9ba9f0020fc6ddb7ar6
  17:        0x10b5c0fe8 - middle::trans::expr::trans_rvalue_dps_unadjusted::he07ca709524b78858S5
  18:        0x10b5bf281 - middle::trans::expr::trans_unadjusted::h85d3b8a83dc2d19eEf5
  19:        0x10b584382 - middle::trans::expr::trans::ha3267407ca5ddba4Ay4
  20:        0x10b5d183d - middle::trans::_match::trans_match::h9f4265fbf73063c376j
  21:        0x10b5c09a7 - middle::trans::expr::trans_rvalue_dps_unadjusted::he07ca709524b78858S5
  22:        0x10b582ee9 - middle::trans::expr::trans_into::hf23cf72a72a546ffGu4
  23:        0x10b58223c - middle::trans::controlflow::trans_stmt_semi::he823a76747e978233J0
  24:        0x10b5818b0 - middle::trans::controlflow::trans_stmt::h81b833b282ae446dQF0
  25:        0x10b583138 - middle::trans::controlflow::trans_block::hd7b32b77ecb61a2bWK0
  26:        0x10b62c502 - middle::trans::base::trans_closure::hb1275bd745d019a30Qg
  27:        0x10b575f1a - middle::trans::base::trans_fn::h3b8a7282ce9f4feco2g
  28:        0x10b573655 - middle::trans::base::trans_item::h71d45f92e9d22ff3Hlh
  29:        0x10b635978 - middle::trans::base::trans_crate::h3a3fd248eb88c863yji
  30:        0x10ba7a355 - driver::driver::phase_4_translate_to_llvm::h7182abf670862972XjA
  31:        0x10ba72fe6 - driver::driver::compile_input::h320087e927cf6176RQz
  32:        0x10baf903f - driver::run_compiler::hc4176702d8610954vDD
  33:        0x10baf71c6 - driver::run::closure.145651
  34:        0x10b20843b - task::TaskBuilder<S>::try_future::closure.103161
  35:        0x10b208323 - task::TaskBuilder<S>::spawn_internal::closure.103132
  36:        0x10c4457fd - task::NativeSpawner.Spawner::spawn::closure.8519
  37:        0x10e86d1dc - rust_try_inner
  38:        0x10e86d1c6 - rust_try
  39:        0x10e804287 - unwind::try::h36b9cbf695564505Jjd
  40:        0x10e80410c - task::Task::run::h3041fca9d0c3b994Uzc
  41:        0x10c445622 - task::NativeSpawner.Spawner::spawn::closure.8458
  42:        0x10e805aca - thread::thread_start::hb7e526bd935a9ae15Tc
  43:     0x7fff940a72fc - _pthread_body
  44:     0x7fff940a7279 - _pthread_body
@alexcrichton
Copy link
Member

Dupe of #18061, but thanks! #18177 should be a fix for this.

lnicola pushed a commit to lnicola/rust that referenced this issue Oct 17, 2024
Run subprocesses async in vscode extension

Extensions should not block the vscode extension host. Replace uses of `spawnSync` with `spawnAsync`, a convenience wrapper around `spawn`.

These `spawnSync`s are unlikely to cause a real issue in practice, because they spawn very short-lived processes, so we aren't blocking for very long. That said, blocking the extension host is poor practice, and if they _do_ block for too long for whatever reason, vscode becomes useless.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants