1.26 local rebuild panicked at 'slice index starts at 1 but ends at 0'

[cuviper]

When testing a local rebuild in Fedora -- using rustc 1.26.0 as stage0 to build rustc 1.26.0 again -- I ran into this ICE:

Building stage0 codegen artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu, llvm)
   Compiling build_helper v0.1.0 (file:///home/jistone/rust/rust/src/build_helper)
thread '<unnamed>' panicked at 'slice index starts at 1 but ends at 0', libcore/slice/mod.rs:791:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: rust_metadata_std_64138f1c4eee6bf8fc01bad227d4339b
   1: rust_metadata_std_64138f1c4eee6bf8fc01bad227d4339b
   2: rust_metadata_std_64138f1c4eee6bf8fc01bad227d4339b
   3: rust_metadata_std_64138f1c4eee6bf8fc01bad227d4339b
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::slice::slice_index_order_fail
   9: rustc_driver::handle_options
             at ./libcore/slice/mod.rs:914
             at ./libcore/slice/mod.rs:997
             at ./libcore/slice/mod.rs:767
             at librustc_driver/lib.rs:1368
  10: rustc_driver::run_compiler_impl
             at librustc_driver/lib.rs:474
  11: syntax::with_globals
             at librustc_driver/lib.rs:457
             at /home/jistone/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.1/src/lib.rs:155
             at ./libsyntax/lib.rs:100
             at /home/jistone/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.1/src/lib.rs:155
             at ./libsyntax/lib.rs:99

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: rustc 1.26.0 (a77568041 2018-05-07) running on x86_64-unknown-linux-gnu

error: Could not compile `build_helper`.

The "slice index starts at 1 but ends at 0" comes from here:

rust/src/librustc_driver/lib.rs

Lines 1366 to 1368 in a775680

	pub fn handle_options(args: &[String]) -> Option<getopts::Matches> {
	// Throw away the first argument, the name of the binary
	let args = &args[1..];

With GDB I found that args is completely empty!

Stepping through from the very beginning, std::rt::lang_start_internal does get the right argc and argv, calling sys::args::init appropriately. But the addresses of sys::unix::args::imp::ARGC and ARGV are not where env::args_os accesses later from librustc_driver, so that just sees 0 and ptr::null().

It turns out that the bootstrap LD_LIBRARY_PATH was causing my /usr/bin/rustc to load the freshly-built libraries, rather than its own in /usr/lib64/. The bootstrap rustc wrapper does try to set a libdir at the front of that path, but it uses $sysroot/lib, here /usr/lib, so that doesn't help.

This only hits local-rebuild, because normal prior-release stage0 builds have different library metadata.

[nikomatsakis]

Is this fixed? cc @kennytm @cuviper

[cuviper]

Sorry, yes, fixed by #50789.