Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: internal compiler error: librustc/hir/def.rs:289: attempted .def_id() on invalid def: Err #54320

Closed
upsuper opened this issue Sep 18, 2018 · 3 comments

Comments

@upsuper
Copy link
Contributor

upsuper commented Sep 18, 2018

Having the following Cargo.toml:

[package]
name = "ice-test"
version = "0.1.0"
authors = ["Xidorn Quan <me@upsuper.org>"]
edition = "2018"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = { git = "https://github.com/rustwasm/wasm-bindgen" }

[dependencies.web-sys]
git = "https://github.com/rustwasm/wasm-bindgen"
features = [
    "Event",
    "UiEvent",
]

and the following lib.rs:

use wasm_bindgen::prelude::*;
use web_sys::KeyboardEvent;

pub fn foo() {
    let a: KeyboardEvent;
}

with the following command:

cargo +nightly build --target wasm32-unknown-unknown

The compiler panics as follow:

error: internal compiler error: librustc/hir/def.rs:289: attempted .def_id() on invalid def: Err
                                                                                
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:586:9              
stack backtrace:                                                                
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace                 
   1: std::sys_common::backtrace::print                                         
   2: std::panicking::default_hook::{{closure}}                                 
   3: std::panicking::default_hook                                              
   4: rustc::util::common::panic_hook                                           
   5: std::panicking::rust_panic_with_hook                                      
   6: std::panicking::begin_panic                                               
   7: rustc_errors::Handler::bug                                                
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}                           
   9: rustc::ty::context::tls::with_opt::{{closure}}                            
  10: rustc::ty::context::tls::with_context_opt                                 
  11: rustc::ty::context::tls::with_opt                                         
  12: rustc::util::bug::opt_span_bug_fmt                                        
  13: rustc::util::bug::bug_fmt                                                 
  14: rustc::middle::dead::MarkSymbolVisitor::handle_definition                 
  15: rustc::hir::intravisit::walk_ty                                           
  16: rustc::hir::intravisit::walk_block                                        
  17: <rustc::middle::dead::MarkSymbolVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_expr
  18: <rustc::middle::dead::MarkSymbolVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_nested_body
  19: rustc::hir::intravisit::walk_item                                         
  20: rustc::middle::dead::check_crate                                          
  21: rustc::util::common::time                                                 
  22: rustc::ty::context::tls::enter_context                                    
  23: <std::thread::local::LocalKey<T>>::with                                   
  24: rustc::ty::context::TyCtxt::create_and_enter                              
  25: rustc_driver::driver::compile_input                                       
  26: rustc_driver::run_compiler_with_pool                                      
  27: rustc_driver::driver::spawn_thread_pool                                   
  28: rustc_driver::run_compiler                                                
  29: <scoped_tls::ScopedKey<T>>::set                                           
  30: syntax::with_globals                                                      
  31: __rust_maybe_catch_panic                                                  
  32: rustc_driver::run                                                         
  33: rustc_driver::main                                                        
  34: std::rt::lang_start::{{closure}}                                          
  35: std::panicking::try::do_call                                              
  36: __rust_maybe_catch_panic                                                  
  37: std::rt::lang_start_internal                                              
  38: main                                                                      
query stack during panic:                                                       
end of query stack                                                              
error: aborting due to previous error                   

Meta:

rustc 1.30.0-nightly (2ab3eba30 2018-09-14)
binary: rustc
commit-hash: 2ab3eba30741652ba538bc2fc2bba9d81a5c84c6
commit-date: 2018-09-14
host: x86_64-apple-darwin
release: 1.30.0-nightly
LLVM version: 8.0
@csmoe csmoe added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Sep 18, 2018
@upsuper
Copy link
Contributor Author

upsuper commented Sep 18, 2018

This is an interesting bug that, if I comment out the unused definition, then this doesn't happen.

If I comment out the use wasm_bindgen::prelude::*;, compiler reports:

error[E0432]: unresolved import `web_sys::KeyboardEvent`

(but not panic)

This is a reduced example. In my project, the compiler panics with some different information, mentioning MIR, but also mentions DefId, so maybe they have the same root cause.

@upsuper
Copy link
Contributor Author

upsuper commented Sep 18, 2018

Also, it doesn't seem to be specific to wasm target. With --target wasm32-unknown-unknown removed, the same panic still happens.

@csmoe csmoe removed the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Sep 18, 2018
@upsuper
Copy link
Contributor Author

upsuper commented Sep 18, 2018

It seems this has been fixed in the latest Nightly...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants