Change:
} } <del> fn pick_col(m: &[Match]) -> uint { fn score(p: &ast::Pat) -> uint { match p.node { ast::PatLit(_) | ast::PatEnum(_, _) | ast::PatRange(_, _) => 1u, ast::PatIdent(_, _, Some(ref p)) => score(&**p), _ => 0u </del> <ins> fn pick_column_to_specialize(def_map: &DefMap, m: &[Match]) -> Option<uint> { fn pat_score(def_map: &DefMap, pat: &ast::Pat) -> uint { match pat.node { ast::PatIdent(_, _, Some(ref inner)) => pat_score(def_map, &**inner), _ if pat_is_refutable(def_map, pat) => 1u, _ => 0u </ins> } } <del> let mut scores = Vec::from_elem(m[0].pats.len(), 0u); for br in m.iter() { for (i, ref p) in br.pats.iter().enumerate() { *scores.get_mut(i) += score(&***p); </del> <ins> let column_score: |&[Match], uint| -> uint = |m, col| { let total_score = m.iter() .map(|row| row.pats[col]) .map(|pat| pat_score(def_map, pat)) .sum(); // Irrefutable columns always go first, they'd only be duplicated in the branches. if total_score == 0 { std::uint::MAX } else { total_score </ins> } <del> } let mut max_score = 0u; let mut best_col = 0u; for (i, score) in scores.iter().enumerate() { let score = *score; // Irrefutable columns always go first, they'd only be duplicated in // the branches. if score == 0u { return i; } // If no irrefutable ones are found, we pick the one with the biggest // branching factor. if score > max_score { max_score = score; best_col = i; } } return best_col; </del> <ins> }; let column_contains_any_nonwild_patterns: |&uint| -> bool = |&col| { m.iter().any(|row| match row.pats[col].node { ast::PatWild(_) => false, _ => true }) }; range(0, m[0].pats.len()) .filter(column_contains_any_nonwild_patterns) .map(|col| (col, column_score(m, col))) .max_by(|&(_, score)| score) .map(|(col, _)| col) </ins> } // Compiles a comparison between two things.

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.) ;)