ICE with array literal in REPL

[lilyball]

If I try and use an array literal in the REPL I get an ICE:

> [1,2,3]
thread '<unnamed>' panicked at 'ICE: Unexpected data type: _. Please report an issue at https://github.com/gluon-lang/gluon/issues', /Users/eridius/.cargo/registry/src/github.com-1ecc6299db9ec823/gluon_vm-0.8.0/src/compiler.rs:834:26

Trying to ask for the type of this expression also just returns _:

> :t [1,2,3]
_

This is with Gluon 0.8.0.

[lilyball]

This also crashes even if I try and provide an explicit type:

> let a: Array Int = [1,2,3]
thread '<unnamed>' panicked at 'ICE: Unexpected data type: _. Please report an issue at https://github.com/gluon-lang/gluon/issues', /Users/eridius/.cargo/registry/src/github.com-1ecc6299db9ec823/gluon_vm-0.8.0/src/compiler.rs:834:26

[Laegluin]

Happens on my pc too. This is the full backtrace:
gluon_array_backtrace.txt

[lilyball]

Pro-tip: you can use a <details> tag to include long text directly in a comment without making the page unwieldy. This looks something like

<details><summary>Optional summary element that defines what's shown without expanding.</summary>
Anything here is hidden until the disclosure triangle is clicked. You can include markdown (e.g. code blocks) by putting a blank line in between the `<details>` and the markdown.
</details>

Here's the full backtrace from my machine

   0:        0x1058a5a5f - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h8c01dd52bd4e31db
   1:        0x105890aed - std::sys_common::backtrace::print::hb3c7e6f524e89fbf
   2:        0x1058ab591 - std::panicking::default_hook::{{closure}}::h8088b27b936dc62a
   3:        0x1058ab28a - std::panicking::default_hook::h0cee2d18d765c6ab
   4:        0x1058abc51 - std::panicking::rust_panic_with_hook::hc2253a5bcda7eda7
   5:        0x1058ab790 - std::panicking::begin_panic_fmt::h2a4ecdf0c76cf1c3
   6:        0x1055e7a68 - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
   7:        0x1055e3099 - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
   8:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
   9:        0x1055e3099 - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  10:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  11:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  12:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  13:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  14:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  15:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  16:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  17:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  18:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  19:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  20:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  21:        0x1055e3099 - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  22:        0x1055e553d - gluon_vm::compiler::Compiler::compile_::h9ba9afc1e808db5e
  23:        0x1055e31ce - gluon_vm::compiler::Compiler::compile::h6ea387fb3ec72e43
  24:        0x1055e2942 - gluon_vm::compiler::Compiler::compile_expr::h647a92320f8e1074
  25:        0x10528d9bf - <gluon::compiler_pipeline::TypecheckValue<E> as gluon::compiler_pipeline::Compileable<Extra>>::compile::hddf807677218810d
  26:        0x1052b464d - <C as gluon::compiler_pipeline::Executable<'vm, Extra>>::run_expr::h0830a75e2184c29d
  27:        0x1053320aa - gluon::repl::load_repl::wrapper::h2c1942f875e00515
  28:        0x1055f2d72 - gluon_vm::thread::OwnedContext::execute::h0b4bb039f940e666
  29:        0x1055f0b74 - <gluon_vm::thread::Thread as gluon_vm::thread::ThreadInternal>::call_function::hd1cb93053882649a
  30:        0x10532797e - <gluon_vm::api::Function<T, fn() .> R>>::call_async::h87adccbdb68ac82d
  31:        0x1052fb282 - <futures::future::lazy::Lazy<F, R> as futures::future::Future>::poll::h32ca555d8a0a251f
  32:        0x10528f51a - std::panicking::try::do_call::h4fb8d3b57c50ffec
  33:        0x1058b74ce - __rust_maybe_catch_panic
  34:        0x10527ea5f - <futures_cpupool::MySender<F, core::result::Result<<F as futures::future::Future>::Item, <F as futures::future::Future>::Error>> as futures::future::Future>::poll::h61f58cb2bcc53ac1
  35:        0x10579fa60 - futures::task_impl::std::set::hc57b0ea53e5e7772
  36:        0x10579fbdb - futures::task_impl::std::Run::run::h8d90eefe4d5fb4fb
  37:        0x10534c17f - futures_cpupool::Inner::work::h9b36d85f6067aef7
  38:        0x105346928 - std::sys_common::backtrace::__rust_begin_short_backtrace::h1828f18c19ff3c1c
  39:        0x1053470f7 - std::panicking::try::do_call::hd5d6929b58c32eac
  40:        0x1058b74ce - __rust_maybe_catch_panic
  41:        0x105346eac - <F as alloc::boxed::FnBox<A>>::call_box::h563af5ac950da443
  42:        0x1058a7f37 - std::sys_common::thread::start_thread::h4258ce81cea6ecca
  43:        0x105894d58 - std::sys::unix::thread::Thread::new::thread_start::h7ac7d9b68b94f18d
  44:     0x7fff617a7660 - _pthread_body
  45:     0x7fff617a750c - _pthread_start

That said, I'm not sure if this backtrace is at all useful (which is why I didn't include it originally), as the backtrace basically just says it's coming from the gluon compiler, but we already knew that from the panic message.

[Marwes]

Fix in #558. Due to the way the repl invokes the typechecker it hit a code path which didn't assign the type as it should have.