1.34.1 crashes in RLS if Vergen is used as a build dependency

[Tomcc]

I don't know much about rustc or the vergen crate... so this issue is more or less an info dump that might or might not be useful :)

I was using Vergen to embed a bit of build information in my binary. It seemed to work fine in a few nightlies I used in the past months, however when I decided to go back to stable-1.34.1, RLS started crashing due to it.

This is the crash log:

{"message":"src\\librustc\\ty\\context.rs:541: node_type: no type for node `expr <Self>::BUILD_TIMESTAMP (id=3775)`","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src\\librustc\\ty\\context.rs:541: node_type: no type for node `expr <Self>::BUILD_TIMESTAMP (id=3775)`\n\n"}
thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:620:9
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: <rustc::ty::sty::Binder<rustc::ty::ProjectionPredicate<'tcx>> as rustc::ty::ToPredicate<'tcx>>::to_predicate
   4: std::panicking::rust_panic_with_hook
   5: <rustc_errors::emitter::ColorConfig as core::fmt::Debug>::fmt
   6: rustc_errors::Handler::bug
   7: rustc::util::bug::bug_fmt
   8: rustc::ty::wf::object_region_bounds
   9: rustc::ty::wf::object_region_bounds
  10: rustc::ty::wf::object_region_bounds
  11: rustc::util::bug::bug_fmt
  12: rustc::util::bug::bug_fmt
  13: rustc::ty::context::TypeckTables::node_type
  14: rustc::ty::context::TypeckTables::expr_ty_adjusted
  15: rustc_save_analysis::SaveContext::get_expr_data
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <rustc_save_analysis::DumpHandler<'a> as rustc_save_analysis::SaveHandler>::save
  24: <env_logger::fmt::WriteStyle as core::default::Default>::default
  25: rustc_driver::enable_save_analysis
  26: rustc_driver::enable_save_analysis
  27: <env_logger::fmt::WriteStyle as core::default::Default>::default
  28: <rustc_driver::CompilationFailure as core::fmt::Debug>::fmt
  29: <rustc_driver::CompilationFailure as core::fmt::Debug>::fmt
  30: <env_logger::fmt::WriteStyle as core::default::Default>::default
  31: rustc_driver::driver::compile_input
  32: rustc_driver::run_compiler
  33: <rustc_driver::CompilationFailure as core::fmt::Debug>::fmt
  34: rustc_driver::run_compiler
  35: git_libgit2_opts
  36: git_libgit2_opts
  37: _rust_maybe_catch_panic
  38: git_libgit2_opts
  39: std::sys::windows::thread::Thread::new
  40: BaseThreadInitThunk
  41: RtlUserThreadStart
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"}

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.34.1 (fc50f328b 2019-04-24) running on x86_64-pc-windows-msvc

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

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

• I'm using the VSCode extension, latest version
• the project builds fine, this only happens in rls in VSCode
• if I remove the vergen dependency, it works fine even in VSCode
• It used to work when I was on nightly 1.36-something
• It doesn't seem to matter if vergen is used at all, which probably means the panic happens within the library itself

Let me know if you need any more info!

EDIT:
I noticed that a minimal project that just depends on vergen does not crash, somehow.

[hellow554]

Can you try to isolate the crash and produce a minimal example (e.g. start with a clean project and try to do the things you have done until it crashes)? It would be awesome.

@rustbot modify labels: I-ICE C-Bug T-dev-tools T-compiler

[jonas-schievink]

Duplicate of #59134

[jonas-schievink]

To confirm, check if your Cargo.lock contains bitflags 1.0.6. You can go back to 1.0.5 to work around this bug (and 1.0.6 has been yanked in the meantime).

[Tomcc]

Oh thanks, yes I do have 1.0.5 in the failing project!
The repro project works, because it pulled 1.0.4... and 1.0.5 doesn't even exist anymore.
I've deleted Cargo.lock, and a new one was recreated with 1.0.4, and that works just fine.

I think you meant that 1.0.5 is bad and I should go back to 1.0.4, right?

[jonas-schievink]

Ah yeah I meant 1.0.5 which is broken (and was yanked), and 1.0.4 which should still work.