ICE in librustc_codegen_llvm when building kernel

[thepowersgang]

Basic issue while I start digging deeper into the issue. Compiling the kernel in https://github.com/thepowersgang/rust_os/tree/4eefae2ce0db2ba62714dbedc31094a756275651 using xargo causes rustc to ICE in librustc_codegen_llvm

In cleaning up for commit, I've isolated it to https://github.com/thepowersgang/rust_os/blob/4eefae2ce0db2ba62714dbedc31094a756275651/Kernel/main/main.rs#L34, which causes the ICE if uncommented.

  Compiling main v0.0.0 (/home/tpg/Projects/rust_os/Kernel)
error: internal compiler error: src/librustc_codegen_llvm/consts.rs:121: must have type `*const T` or `*mut T`

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:634:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   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_codegen_llvm::consts::check_and_apply_linkage
  15: rustc_codegen_llvm::consts::<impl rustc_codegen_llvm::context::CodegenCx>::get_static
  16: rustc_codegen_llvm::common::<impl rustc_codegen_ssa::traits::consts::ConstMethods for rustc_codegen_llvm::context::CodegenCx>::scalar_to_backend
  17: rustc_codegen_llvm::consts::const_alloc_to_llvm
  18: rustc_codegen_llvm::common::<impl rustc_codegen_ssa::traits::consts::ConstMethods for rustc_codegen_llvm::context::CodegenCx>::scalar_to_backend
  19: rustc_codegen_llvm::consts::const_alloc_to_llvm
  20: rustc_codegen_llvm::consts::codegen_static_initializer
  21: rustc_codegen_llvm::consts::<impl rustc_codegen_ssa::traits::statics::StaticMethods for rustc_codegen_llvm::context::CodegenCx>::codegen_static
  22: rustc_codegen_ssa::mono_item::MonoItemExt::define
  23: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
  24: rustc::dep_graph::graph::DepGraph::with_task
  25: rustc_codegen_llvm::base::compile_codegen_unit
  26: rustc_codegen_ssa::base::codegen_crate
  27: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  28: rustc::util::common::time
  29: rustc_interface::passes::start_codegen
  30: rustc::ty::context::tls::enter_global
  31: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  32: rustc_interface::passes::create_global_ctxt::{{closure}}
  33: rustc_interface::passes::BoxedGlobalCtxt::enter
  34: rustc_interface::queries::Query<T>::compute
  35: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen
  36: rustc_interface::interface::run_compiler_in_existing_thread_pool
  37: std::thread::local::LocalKey<T>::with
  38: scoped_tls::ScopedKey<T>::set
  39: syntax::with_globals
query stack during panic:
end of query stack
error: aborting due to previous error


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.35.0-nightly (e782d790f 2019-03-29) running on x86_64-unknown-linux-gnu

note: compiler flags: -C opt-level=3 -C target-feature= --crate-type staticlib

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

error: Could not compile `main`.

[pnkfelix]

triage: P-high, removing I-nominated tag since there is little to discuss beyond P-highness.

Important next step is to create an isolated test case (either a crate, or ideally, a single file or even snippet that reproduces on play.rust-lang.org), so that we do not risk losing track of the problematic code from an external repository.

[thepowersgang]

Will do, I suspect it's related to referencing a #[linkage="external"] variable from a static. Removing the external linkage on the target symbol removes the ICE.

[thepowersgang]

Confirmed: Using a minimal reproduction with the following files (Cargo.toml files omitted for brevity)

src/main.rs

extern crate depfoo;
fn main() {
        println!("{:p}", &depfoo::EXTERN);
}

depfoo/src/lib.rs

#![feature(linkage)]
#[linkage="external"]
pub static EXTERN: u32 = 0;

Results in the ICE:

Press ENTER or type command to continue
   Compiling foo v0.0.0 (/home/tpg/tmp/rustc-59548)
error: internal compiler error: src/librustc_codegen_llvm/consts.rs:121: must have type `*const T` or `*mut T`

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:605:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error

[pnkfelix]

ah, this may be a known limitation of #[linkage]...

did this code use to compile under a previous version of Rust?

[thepowersgang]

Don't know - this was a new piece of code (the reference to the linkage-marked variable was added as part of moving to an xargo-based build)

[pnkfelix]

triage: Assigning to self to look into whether this is known limitation of #[linkage], and if so, replacing the ICE with a proper diagnostic.

[pnkfelix]

So there's a couple interesting things here:

First: the ICE itself originates here:

rust/src/librustc_codegen_llvm/consts.rs

Lines 100 to 106 in 4680580

	fn check_and_apply_linkage(
	cx: &CodegenCx<'ll, 'tcx>,
	attrs: &CodegenFnAttrs,
	ty: Ty<'tcx>,
	sym: LocalInternedString,
	span: Option<Span>
	) -> &'ll Value {

...

rust/src/librustc_codegen_llvm/consts.rs

Lines 119 to 123 in 4680580

	if let Some(span) = span {
	cx.sess().span_fatal(span, "must have type `*const T` or `*mut T`")
	} else {
	bug!("must have type `*const T` or `*mut T`")
	}

i.e., the ICE is happening because we aren't providing a Span, at this call here:

rust/src/librustc_codegen_llvm/consts.rs

Line 263 in 4680580

let g = check_and_apply_linkage(&self, &attrs, ty, sym, None);

So one option would be to attempt to figure out some Span to supply. That, or stop requiring a Span, and issue an error anyway.

---

Second: one would imagine we should be issuing the diagnostic complaining about the type at the point where the attribute is attached to the item; i.e., at the point where we are compiling depfoo.rs. But currently that is not what happens; currently we wait until the usage itself to do the check that the linkage makes sense, and do no checking at the definition site.

[pnkfelix]

Okay so it turns out that its pretty trivial to fix the first problem I mentioned above. I'll have a PR up with that shortly.

It is probably also easy to fix the second problem, but such a change is a little bit more risky, since it will "break" hypothetical code that compiles today (namely, code that defines a static with some #[linkage] but never uses that static. So I'll make sure to put that in a totally separate PR.