Unable to clone large nested array

[davidjohnstone]

This compiles and runs when SIZE is 32, but won't compile when SIZE is 64.

const SIZE: usize = 64;

fn main() {
    let grid = [[100.0f64; SIZE]; SIZE];
    let cloned = grid.clone();
    println!("{}", cloned[0][0]);
}

For this bit of code the error is:

crash.rs:5:23: 5:30 error: type `[[f64; 64]; 64]` does not implement any method in scope named `clone`
crash.rs:5     let cloned = grid.clone();

I found this in a larger program which gives the following error:

src\gen.rs:103:38: 103:45 error: type `[[f64; 64]; 64]` does not implement any method in scope named `clone`
src\gen.rs:103         let mut new_grid = self.grid.clone();
                                                    ^~~~~~~
error: internal compiler error: no type for expr in fcx 0x3feed78
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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', C:/bot/slave/stable-dist-rustc-win-64/build/src/libsyntax\diagnostic.rs:209

stack backtrace:
   1:         0x711b7518 - sys::backtrace::write::h18c35e883c391343Fgs
   2:         0x711c0531 - rt::unwind::register::h363bfdd0c210a6f9Pzv
   3:         0x71185070 - rt::unwind::begin_unwind_inner::h87ae4ef2e31e9162Zwv
   4:           0x4f9e39 - diagnostic::SpanHandler::span_bug::h1291a8e5c3fbff5d3qB
   5:           0x4fa43e - diagnostic::Handler::bug::he3286c5af7a7ae2aFwB
   6:           0xc5dd69 - session::Session::bug::h2538e212344e74e6kDq
   7:          0x13b8434
   8:          0x13cc9ed - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
   9:          0x13ccdff - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  10:          0x13ccdee - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  11:          0x13cd4a8 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  12:          0x13ccfde - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  13:          0x13cd45a - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  14:          0x13cd3e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  15:          0x13cce85 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  16:          0x13cd3e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  17:          0x13d00e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_local::h4694e33d977bf982Jic
  18:          0x13cd45a - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  19:          0x13cce85 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  20:          0x13cd3e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  21:          0x13cce85 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  22:          0x13cd3e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  23:          0x13d00e9 - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_local::h4694e33d977bf982Jic
  24:          0x13cd45a - check::writeback::WritebackCx<'cx, 'tcx>.Visitor<'v>::visit_expr::hb94381c3b15d39e7bdc
  25:          0x1451dbb - check::CheckItemBodiesVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::hdd59e39b3baccea3wtn
  26:          0x145a67a - check::GatherLocalsVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::hf0a20e9df6a05621CGn
  27:          0x144fa4b - check::CheckItemBodiesVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::hdd59e39b3baccea3wtn
  28:          0x144fdbf - check::CheckItemBodiesVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::hdd59e39b3baccea3wtn
  29:          0x150e88b - check_crate::hdbb111d3237a4f46XcC
  30:          0x15099d9 - check_crate::hdbb111d3237a4f46XcC
  31:         0x652e2609 - driver::phase_3_run_analysis_passes::h5b5c80d034aa4ed9nGa
  32:         0x652c2a9f - driver::compile_input::hc7c73f26222a4410Qba
  33:         0x6537ff53 - run_compiler::h0182d12bd030b5b8z4b
  34:         0x6537de1f - run::h96a163d710b95e7af4b
  35:         0x6537d26a - run::h96a163d710b95e7af4b
  36:         0x711f485c - rust_try
  37:         0x711f4839 - rust_try
  38:         0x6537d519 - run::h96a163d710b95e7af4b
  39:         0x711be984 - sys::process2::Command::cwd::h7f278c19a549c55dKfu
  40:     0x7ffa79e913d2 - BaseThreadInitThunk

Happens for both 1.0.0 and Nightly. Windows 8. 64 bit.

[oli-obk]

related to #25733 and #24000

[steveklabnik]

In general, things are only implemented up to size 32. https://github.com/rust-lang/rust/blob/master/src/libcore/array.rs#L162-L167

This is effectively a dup of rust-lang/rfcs#1038 , so I'm giving it a close. Sorry about that, @davidjohnstone . For now, you'll have to use a Vec<T>.

[davidjohnstone]

Cheers. I didn't find anything that seemed relevant in my searching, and based on my two days of Rust programming this behaviour seemed rather unintuitive.

[steveklabnik]

You'll see it with tuples too. even though the RFC thread doesn't say much, this is a relatively highly requested feature, because as you've found out, it makes array usage really awkward.

[shepmaster]

@steveklabnik Clone may not be implemented, but isn't the ICE unexpected?

[steveklabnik]

@shepmaster i assumed that this ICE was the same as the one in the linked issues, maybe not?