internal compiler error: 'rustc' panicked at 'No def'n found for DefId { krate: 0, node: 4 } in tcx.tcache'

[Coreknot]

Just started experimenting with Rust, but as soon as I try to use a Module, compilation fails.

Code: main.rs: mod person;

fn main() { let p = person{ name : "Example" }; p.say_hello(); }

person.rs: struct person { name : String, }

impl person { fn say_hello(&self){ println!("Hello {}", self.name); } }

---

Compiling test v0.0.1 (file:///home/_/work/test) Running `rustc main.rs --crate-name test --crate-type bin -g --out-dir /home/_/work/test/target >--emit=dep-info,link -L dependency=/home/_/work/test/target -L dependency=/home/_/work/test/target/deps error: internal compiler error: unexpected panic 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 withRUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'No def'n found for DefId { krate: 0, node: 4 } in tcx.tcache', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc/middle/ty.rs:5141

Could not compile test.

Caused by: Process didn't exit successfully: rustc main.rs --crate-name test --crate-type bin -g --out-dir >/home/****/work/test/target --emit=dep-info,link -L dependency=/home/****/work/test/target -L >dependency=/home/****/work/test/target/deps (exit code: 101)

---

rustc 1.0.0-nightly (2fc8b1e7c 2015-03-07) (built 2015-03-08) binary: rustc commit-hash: 2fc8b1e7c4ca741e59b144c331d69bf189759452 commit-date: 2015-03-07 build-date: 2015-03-08 host: x86_64-unknown-linux-gnu release: 1.0.0-nightly

---

Backtrace: Compiling test v0.0.1 (file:///home/****/work/test) thread 'rustc' panicked at 'No def'n found for DefId { krate: 0, node: 4 } in tcx.tcache', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc/middle/ty.rs:5141

stack backtrace: 1: 0x7f8c5cdaa2d2 - sys::backtrace::write::h49f84a63c90f3a72QBA 2: 0x7f8c5cdd0322 - panicking::on_panic::hd99ba6230147c149jHJ 3: 0x7f8c5cd16a69 - rt::unwind::begin_unwind_inner::hcba984cddf911653mnJ 4: 0x7f8c5cd16e11 - rt::unwind::begin_unwind_fmt::h056d56048d7d024dXlJ 5: 0x7f8c5adf820c - middle::ty::lookup_item_type::h6ab48efb47b1c189TU7 6: 0x7f8c5bbf89a3 - check::check_expr_with_unifier::h7241075278574285947 7: 0x7f8c5bc1a62d - check::check_decl_local::h554e5d2066e836d5IWr 8: 0x7f8c5bbd2190 - check::check_block_with_expected::h4d6fd0761db904b4P2r 9: 0x7f8c5bbba2d2 - check::check_fn::hbe3c2620378bc01ffmn 10: 0x7f8c5bbcf943 - check::check_bare_fn::h560cf773e203be14Vbn 11: 0x7f8c5bbc7f1f - check::check_item::ha45b9554a5eca7eazun 12: 0x7f8c5bc878b3 - check_crate::closure.35693 13: 0x7f8c5bc833d7 - check_crate::h2872530e4373c1cbhfC 14: 0x7f8c5d3c585e - driver::phase_3_run_analysis_passes::hd173921852ab87d4mGa 15: 0x7f8c5d3aa6d5 - driver::compile_input::h552c440872c5b657Nba 16: 0x7f8c5d46ef1d - run_compiler::h56042a784d7b1fc7G6b 17: 0x7f8c5d46cc8c - thunk::F.Invoke<A, R>::invoke::h15113937807686641913 18: 0x7f8c5d46b8e0 - rt::unwind::try::try_fn::h14840337430372503284 19: 0x7f8c5ce3c0f8 - rust_try_inner 20: 0x7f8c5ce3c0e5 - rust_try 21: 0x7f8c5d46c06b - thunk::F.Invoke<A, R>::invoke::h6250943894687305386 22: 0x7f8c5cdbdb25 - sys::thread::thread_start::h848d60956d3aea28t8E 23: 0x7f8c56e2a373 - start_thread 24: 0x7f8c5c99f27c - __clone 25: 0x0 -

[jdm]

Apparently we don't properly handle the case of trying to instantiate a structure using the name of a module.

[Gordin]

Was about to open a new Issue but I guess I'm having the same problem here. This will be an update that this still happens in rustc 1.3.0-nightly (98dcd5e10 2015-07-11) as well as in stable 1.1.0.

I tried to write a very simple rust program split into two files. I couldn't figure out the right way to use modules from the documentation so I did trial and error for a bit and ended up with a compiler panic. I know my code most likely isn't even supposed to work and naming conventions are not followed, it still shouldn't crash the compiler though.

I wrote this code: https://github.com/Gordin/rust-compiler-bug and tried to compile/run it like this: rustc src/main.rs or cargo run

I expected to see this happen: Either that the compilation works or some kind of Warning that I'm using modules wrong. I'm not sure yet…

Instead, this happened: The compiler panicked. The Backtrace below is frow the current nightly build, but it also happens in 1.1.0.

Meta

rustc --version --verbose: rustc 1.3.0-nightly (98dcd5e10 2015-07-11) binary: rustc commit-hash: 98dcd5e10aba490286abcae81b971a0206a9fd47 commit-date: 2015-07-11 host: x86_64-unknown-linux-gnu release: 1.3.0-nightly

Backtrace:

error: internal compiler error: unexpected panic 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 thread 'rustc' panicked at 'No def'n found for DefId { krate: 0, node: 7 }field::Point in tcx.tcache', ../src/librustc/middle/ty.rs:5131

stack backtrace: 1: 0x7f41213a64be - sys::backtrace::write::h71d29b1bac79e8cbpps 2: 0x7f41213ae684 - panicking::on_panic::h388ac0d9b2121cf0jbx 3: 0x7f4121370efe - rt::unwind::begin_unwind_inner::ha58af1582e1c2742XQw 4: 0x7f4121371c2c - rt::unwind::begin_unwind_fmt::h0f4d16c8393c489b3Pw 5: 0x7f411f410d12 - middle::ty::ctxt<'tcx>::lookup_item_type::hf32c8623c76b3323zAa 6: 0x7f4120bbe248 - check::check_expr_with_unifier::h8777461280675780606 7: 0x7f4120be24ab - check::check_decl_initializer::hfcc2204f454c0bb6DSr 8: 0x7f4120be256d - check::check_decl_local::hc1aa1c1287452038RTr 9: 0x7f4120be2799 - check::check_stmt::h826e52710b10ea3bKVr 10: 0x7f4120b92143 - check::check_block_with_expected::h38284c66f76fa1bfOZr 11: 0x7f4120b75e94 - check::check_fn::h8138f491a7668d40IFn 12: 0x7f4120b8c648 - check::check_bare_fn::ha9dfedbc4fbb9e43lvn 13: 0x7f4120b8a5b3 - check::check_item_body::hb210612b336a05e6YVn 14: 0x7f4120b8c274 - check::check_item_types::h1193f82292001566Ssn 15: 0x7f4120c491cb - check_crate::h23300ff0f42a0847uWC 16: 0x7f412190bd29 - driver::phase_3_run_analysis_passes::closure.15891 17: 0x7f412190a66b - middle::ty::ctxt<'tcx>::create_and_enter::h6443859835779211321 18: 0x7f4121905611 - driver::phase_3_run_analysis_passes::h9476676314952095677 19: 0x7f41218e486c - driver::compile_input::h681a082b6bc6d1d7Tba 20: 0x7f41219cb153 - run_compiler::heebd9d542947b5bcA7b 21: 0x7f41219c8b2e - boxed::F.FnBox::call_box::h16949736314100607065 22: 0x7f41219c8379 - rt::unwind::try::try_fn::h15085409492537019460 23: 0x7f41214296e8 - rust_try_inner 24: 0x7f41214296d5 - rust_try 25: 0x7f41213997f7 - rt::unwind::try::inner_try::h16bcf985c725dc7aQMw 26: 0x7f41219c858b - boxed::F.FnBox::call_box::h16241011151202459548 27: 0x7f41213ad2e1 - sys::thread::Thread::new::thread_start::he7052da0f20591f3DWv 28: 0x7f411b037343 - start_thread 29: 0x7f41210062ac - __clone 30: 0x0 -

Triage: being tracked by glacier.

[Mark-Simulacrum]

...Or not? Glacier appears to be passing, but this is fixed as far as I can tell. Marking both examples as E-needstest.