compiler panic on OS X: 'can't create relative paths across filesystems' (regression)

[comex]

The -C rpath option, which has always been nonfunctional on OS X, now causes a compiler panic. (I only came across this by accident, because I never removed the option from my makefile after attempting to use it at the time I filed that issue.)
In this case, relativize in src/librustc_back/rpath.rs is being called with the arguments "/opt/lru/lib/rustlib/x86_64-apple-darwin/lib" and "/private/tmp". There is actually only one filesystem involved, although I'm not sure why mounts would prevent relative paths from being created.

/tmp % echo 'fn main() {}' > hello.rs
/tmp % RUST_BACKTRACE=1 rustc -C rpath hello.rs
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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'can't create relative paths across filesystems', /usr/src/rust/src/librustc_back/rpath.rs:116

stack backtrace:
   1:        0x1085b19f2 - sys::backtrace::write::h89574ef9ad8da186IDA
   2:        0x1085e06e4 - panicking::on_panic::h1655b4d25b76f374KsJ
   3:        0x1084fea17 - rt::unwind::begin_unwind_inner::h3ddd849238a7da75gbJ
   4:        0x107b3d7ef - rt::unwind::begin_unwind::h7573310346249346792
   5:        0x107b4cbc1 - iter::Map<I, F>.Iterator::next::h396994352844314702
   6:        0x107b4a030 - rpath::get_rpath_flags::ha1faad453319fd57kJa
   7:        0x1053d7dff - back::link::link_args::hd057865f4867d7c3P8a
   8:        0x1053cf610 - back::link::link_natively::h36f064e1db73f7151Ya
   9:        0x1053c9b92 - back::link::link_binary::h097ac40aed1612f9Xua
  10:        0x104e38831 - driver::phase_6_link_output::h70b0959e4cea3cc2wQa
  11:        0x104e12809 - driver::compile_input::h0d9defea3d543c79Nba
  12:        0x104edf98e - run_compiler::h398e6070731ba5e8x6b
  13:        0x104edcf17 - thunk::F.Invoke<A, R>::invoke::h5983203227732868562
  14:        0x104edba5f - rt::unwind::try::try_fn::h17247463931895016429
  15:        0x10865fdc8 - rust_try_inner
  16:        0x10865fdb5 - rust_try
  17:        0x104edc298 - thunk::F.Invoke<A, R>::invoke::h9014748806194985157
  18:        0x1085c8f42 - sys::thread::thread_start::h00dcf94d31b0c0c312E
  19:     0x7fff86d7c267 - _pthread_body
  20:     0x7fff86d7c1e4 - _pthread_start

[japaric]

I'm seeing the same ICE on Linux if I try to use rustc, with cwd = /tmp (tmpfs), on a source file that's in my home directory:

$ pwd
/home/japaric/tmp
$ echo 'fn main() {}' > main.rs
$ cd /tmp
$ RUST_BACKTRACE=1 rustc ~/tmp/main.rs
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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'can't create relative paths across filesystems', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc_back/rpath.rs:115

stack backtrace:
   1:     0x7fc6d98ba2d2 - sys::backtrace::write::h49f84a63c90f3a72QBA
   2:     0x7fc6d98e0322 - panicking::on_panic::hd99ba6230147c149jHJ
   3:     0x7fc6d9826a69 - rt::unwind::begin_unwind_inner::hcba984cddf911653mnJ
   4:     0x7fc6d2daf27c - rt::unwind::begin_unwind::h6703412169040021632
   5:     0x7fc6d2dbf770 - iter::Map<I, F>.Iterator::next::h14795343113335188906
   6:     0x7fc6d2dbd5fa - rpath::get_rpath_flags::h8689aee4bd8a62f8gOa
   7:     0x7fc6d8f51eb6 - back::link::link_args::h0e423504e9a162a3N8a
   8:     0x7fc6d8f4b322 - back::link::link_natively::hecf7c6e78d069d36ZYa
   9:     0x7fc6d8f45d41 - back::link::link_binary::h733fe2e8be711bc3Vua
  10:     0x7fc6d9ee0cbe - driver::phase_6_link_output::hca89f23f478effacwQa
  11:     0x7fc6d9ebaf99 - driver::compile_input::h552c440872c5b657Nba
  12:     0x7fc6d9f7ef1d - run_compiler::h56042a784d7b1fc7G6b
  13:     0x7fc6d9f7cc8c - thunk::F.Invoke<A, R>::invoke::h15113937807686641913
  14:     0x7fc6d9f7b8e0 - rt::unwind::try::try_fn::h14840337430372503284
  15:     0x7fc6d994c0f8 - rust_try_inner
  16:     0x7fc6d994c0e5 - rust_try
  17:     0x7fc6d9f7c06b - thunk::F.Invoke<A, R>::invoke::h6250943894687305386
  18:     0x7fc6d98cdb25 - sys::thread::thread_start::h848d60956d3aea28t8E
  19:     0x7fc6d393a373 - start_thread
  20:     0x7fc6d94af27c - __clone
  21:                0x0 - <unknown>

$ rustc -Vv
rustc 1.0.0-nightly (2fc8b1e7c 2015-03-07) (built 2015-03-08)
binary: rustc
commit-hash: 2fc8b1e7c4ca741e59b144c331d69bf189759452
commit-date: 2015-03-07
build-date: 2015-03-08
host: x86_64-unknown-linux-gnu
release: 1.0.0-nightly

This was working a few days ago: rustc 1.0.0-nightly (3b3bb0e68 2015-03-04) (built 2015-03-05)

[brson]

This also makes rustc unusable in my normal setup.

[sfackler]

Same here

[brson]

It looks to me like the old Path type's path_relative_from handled the case where both paths were absolute with no common prefix, and the new relative_from does not (nor does the rpath-specific relativize function that was added).

[brson]

I have a patch for this.