Change:
return; } <del> let col_count = m[0].pats.len(); if col_count == 0u { let data = &m[0].data; for &(ref ident, ref value_ptr) in m[0].bound_ptrs.iter() { let llmatch = data.bindings_map.get(ident).llmatch; call_lifetime_start(bcx, llmatch); Store(bcx, *value_ptr, llmatch); </del> <ins> let tcx = bcx.tcx(); let def_map = &tcx.def_map; match pick_column_to_specialize(def_map, m) { Some(col) => { let val = vals[col]; if has_nested_bindings(m, col) { let expanded = expand_nested_bindings(bcx, m, col, val); compile_submatch_continue(bcx, expanded.as_slice(), vals, chk, col, val, has_genuine_default) } else { compile_submatch_continue(bcx, m, vals, chk, col, val, has_genuine_default) } </ins> } <del> match data.arm.guard { Some(ref guard_expr) => { bcx = compile_guard(bcx, &**guard_expr, m[0].data, m[1..m.len()], vals, chk, has_genuine_default); </del> <ins> None => { let data = &m[0].data; for &(ref ident, ref value_ptr) in m[0].bound_ptrs.iter() { let llmatch = data.bindings_map.get(ident).llmatch; call_lifetime_start(bcx, llmatch); Store(bcx, *value_ptr, llmatch); </ins> } <del> _ => () </del> <ins> match data.arm.guard { Some(ref guard_expr) => { bcx = compile_guard(bcx, &**guard_expr, m[0].data, m[1..m.len()], vals, chk, has_genuine_default); } _ => () } Br(bcx, data.bodycx.llbb); </ins> } <del> Br(bcx, data.bodycx.llbb); return; } let col = pick_col(m); let val = vals[col]; if has_nested_bindings(m, col) { let expanded = expand_nested_bindings(bcx, m, col, val); compile_submatch_continue(bcx, expanded.as_slice(), vals, chk, col, val, has_genuine_default) } else { compile_submatch_continue(bcx, m, vals, chk, col, val, has_genuine_default) </del> } }

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)