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

Rustc panics while compiling gstreamer in RLS #64659

Closed
haecker-felix opened this issue Sep 21, 2019 · 14 comments · Fixed by #65353
Closed

Rustc panics while compiling gstreamer in RLS #64659

haecker-felix opened this issue Sep 21, 2019 · 14 comments · Fixed by #65353
Assignees
Labels
A-save-analysis Area: saving results of analyses such as inference and borrowck results to a file. C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@haecker-felix
Copy link

haecker-felix commented Sep 21, 2019

RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine.

rustc 1.39.0-nightly (eceec57f7 2019-09-18)
x86_64-unknown-linux-gnu

Affected project for reference: https://gitlab.gnome.org/World/Shortwave

I launched RLS manually with RUST_LOG=rls=debug rls --cli

{"message":"src/librustc/ty/context.rs:211: node type <I>::Item (hir_id=HirId { owner: DefIndex(4352), local_id: 4 }) with HirId::owner DefId(0:4352 ~ gstreamer[a0c2]::buffer[0]::{{impl}}[3]::fmt[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:4346 ~ gstreamer[a0c2]::buffer[0]::{{impl}}[3]::fmt[0])","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src/librustc/ty/context.rs:211: node type <I>::Item (hir_id=HirId { owner: DefIndex(4352), local_id: 4 }) with HirId::owner DefId(0:4352 ~ gstreamer[a0c2]::buffer[0]::{{impl}}[3]::fmt[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:4346 ~ gstreamer[a0c2]::buffer[0]::{{impl}}[3]::fmt[0])\n\n"}
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9
stack backtrace:
{"artifact":"/home/haecker-felix/Dokumente/Projekte/Shortwave/target/rls/debug/deps/diesel-d084ca5a95a852d7.d","emit":"dep-info"}
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:60
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
  12: std::panicking::begin_panic
  13: rustc_errors::Handler::bug
  14: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  15: rustc::ty::context::tls::with_opt::{{closure}}
  16: rustc::ty::context::tls::with_context_opt
  17: rustc::ty::context::tls::with_opt
  18: rustc::util::bug::opt_span_bug_fmt
  19: rustc::util::bug::bug_fmt
  20: rustc::ty::context::validate_hir_id_for_typeck_tables::{{closure}}
  21: rustc::ty::context::tls::with::{{closure}}
  22: rustc::ty::context::tls::with_context::{{closure}}
  23: rustc::ty::context::tls::with_context_opt
  24: rustc::ty::context::tls::with_context
  25: rustc::ty::context::tls::with
  26: rustc::ty::context::TypeckTables::qpath_res
  27: rustc_save_analysis::SaveContext::get_path_res
  28: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_ty
  29: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_generics
  30: rustc_save_analysis::dump_visitor::DumpVisitor::process_generic_params
  31: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_item
  32: rustc_save_analysis::dump_visitor::DumpVisitor::process_method::{{closure}}
  33: rustc_save_analysis::dump_visitor::DumpVisitor::process_method
  34: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_item
  35: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_item
  36: <rustc_save_analysis::dump_visitor::DumpVisitor as syntax::visit::Visitor>::visit_mod
  37: rustc::dep_graph::graph::DepGraph::with_ignore
  38: rustc_driver::run_compiler::{{closure}}::{{closure}}::{{closure}}
  39: rustc::util::common::time
  40: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  41: rustc_interface::passes::create_global_ctxt::{{closure}}
  42: rustc_interface::interface::run_compiler_in_existing_thread_pool
  43: std::thread::local::LocalKey<T>::with
  44: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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: rustc 1.39.0-nightly (eceec57f7 2019-09-18) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"}
{"artifact":"/home/haecker-felix/Dokumente/Projekte/Shortwave/target/rls/debug/deps/save-analysis/libdiesel-d084ca5a95a852d7.json","emit":"save-analysis"}
{"artifact":"/home/haecker-felix/Dokumente/Projekte/Shortwave/target/rls/debug/deps/libdiesel-d084ca5a95a852d7.rmeta","emit":"metadata"}
{"artifact":"/home/haecker-felix/Dokumente/Projekte/Shortwave/target/rls/debug/deps/libdiesel-d084ca5a95a852d7.rlib","emit":"link"}
[2019-09-21T13:59:02Z DEBUG rls::build::cargo] error running `compile_with_exec`: ErrorMessage { msg: "build failed" }

stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new
   1: failure::backtrace::Backtrace::new
   2: cargo::core::compiler::job_queue::JobQueue::drain_the_queue
   3: std::panicking::try::do_call
   4: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
   5: crossbeam_utils::thread::scope
   6: cargo::core::compiler::job_queue::JobQueue::execute
   7: cargo::core::compiler::context::Context::compile
   8: cargo::ops::cargo_compile::compile_ws
   9: cargo::ops::cargo_compile::compile_with_exec
  10: rls::build::cargo::run_cargo_ws
  11: rls::build::cargo::run_cargo
  12: std::sys_common::backtrace::__rust_begin_short_backtrace
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  15: core::ops::function::FnOnce::call_once{{vtable.shim}}
  16: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/eceec57f72150dd548e05025a05a93381da41385/src/liballoc/boxed.rs:922
  17: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/eceec57f72150dd548e05025a05a93381da41385/src/liballoc/boxed.rs:922
      std::sys_common::thread::start_thread
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:79
  18: start_thread
             at pthread_create.c:479
  19: clone

{"jsonrpc":"2.0","method":"window/progress","params":{"done":true,"id":"progress_1","message":null,"percentage":null,"title":"Building"}}
{"jsonrpc":"2.0","method":"window/progress","params":{"done":null,"id":"progress_0","message":null,"percentage":null,"title":"Indexing"}}
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"message":"build failed\nerror: Could not compile `gstreamer`.\n","range":{"end":{"character":0,"line":9999},"start":{"character":0,"line":0}},"severity":1}],"uri":"file:///home/haecker-felix/Dokumente/Projekte/Shortwave/Cargo.toml"}}

@haecker-felix haecker-felix changed the title RLS cannot build gstreamer Rustc panics while compiling gstreamer in RLS Sep 21, 2019
@jonas-schievink
Copy link
Contributor

Probably unearthed by #64250

@jonas-schievink jonas-schievink added A-rls A-save-analysis Area: saving results of analyses such as inference and borrowck results to a file. C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 21, 2019
@jonas-schievink
Copy link
Contributor

cc @Xanewok

@haecker-felix
Copy link
Author

Recompiled everything with rustc 1.39.0-nightly (97e58c0d3 2019-09-20), same issue.

@haecker-felix
Copy link
Author

2019-09-13 works fine.

@Xanewok
Copy link
Member

Xanewok commented Sep 21, 2019

I’m sure it’s what @jonas-schievink - it’s an unearthed bug when you pass -Zsave-analysis, hence why it crashes only when using RLS.

@bikeshedder
Copy link

I have the same error when using rust nightly and directly or indirectly referencing the petgraph crate. The project builds fine but rls crashes.

Steps to reproduce:

  • Create a new project
  • Add petgraph = "0.4" to the Cargo.toml
  • Run rls --cli

Downgrading to rustc 1.39.0-nightly (eb48d6bde 2019-09-12) and rls 1.39.0 (412fb00 2019-09-09) makes the error go away.

@pnkfelix pnkfelix added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Sep 26, 2019
@pnkfelix
Copy link
Member

pre-triage: not sure what priority to assign to this. Probably P-high but I want to discuss with team. Leaving I-nominated unprioritized for now.

@pnkfelix
Copy link
Member

triage: P-high. Cc @Xanewok (can you take point on this?)

@pnkfelix pnkfelix added P-high High priority and removed I-nominated labels Sep 26, 2019
@Xanewok Xanewok self-assigned this Sep 26, 2019
@Xanewok
Copy link
Member

Xanewok commented Sep 26, 2019

Yup, assigning to myself, shouldn’t be hard to fix

@kellytk
Copy link

kellytk commented Oct 7, 2019

@Xanewok What assistance from others, if any, could help you resolve this issue?

@sinkuu
Copy link
Contributor

sinkuu commented Oct 8, 2019

Minimal reproducer (based on petgraph ICE):

// compile-flags: -Zsave-analysis

trait NodeIndexable { type NodeId; }
impl<T> NodeIndexable for T { type NodeId = (); }

fn main() {
    struct Data<T: NodeIndexable> {
        x: T::NodeId,
    }
}

@norru
Copy link

norru commented Oct 10, 2019

@Xanewok Is anyone else available you can offload this bug to?

@pnkfelix
Copy link
Member

visiting for triage. Assigning to self to remember to look into this later

@pnkfelix pnkfelix self-assigned this Oct 10, 2019
@Xanewok
Copy link
Member

Xanewok commented Oct 12, 2019

So I have a fix that does not ICE but doesn't seem to actually 'fix' the behaviour. The problem is that we can't nest typeck tables for Data because it doesn't have one because it doesn't have a body; however we hit the assertion when trying to resolve member type T::NodeId when resolving a qualified path using qpath_res because the DefId paths don't properly match.

The fix that I have is not to try to nest when a given NodeId doesn't have associated typeck_tables but instead use an empty table approach (e.g. used in privacy code). This means we don't hit the assertion but IIUC we can't properly resolve a qualified path this way.

I think long-term the solution would be to traverse HIR directly rather than doing so using AST (that's another case where we have a mismatch of nested DefIds for which we can't get typeck tables to properly resolve a QPath). I'll submit the PR with the fix later today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-save-analysis Area: saving results of analyses such as inference and borrowck results to a file. C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants