rustdoc should not assume current_exe() is infallible

[rotty]

On OpenBSD, the std::env::current_exe() function fails if the binary is not invoked with a full path (see this comment). This leads to the following crash when running doc tests:

% cargo test
[...]
   Doc-tests zmq
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: StringError("no current exe available (short)") }', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Note that this using rustc/cargo 1.33.0, installed on OpenBSD 6.5 using its native package (pkg_add rust).

The offending code, I believe, must be one of the current_exe() calls in src/librustdoc/test.rs, which are both unwrapped, and have to do with figuring out the sysroot, if not already known.

The issue can be worked around by adjusting the command line like this:

% RUSTDOCFLAGS='--sysroot /usr/local' cargo test

I guess solving this completely may be tricky, but I think the code should definitely not panic, and ideally cargo/rustdoc would issue an error message pointing (OpenBSD) users to the workaround.

[rotty]

It seems that simply using the code of get_or_default_sysroot() from librustc::session::filesearch would be an improvement over using current_exe() directly; the latter is patched on OpenBSD to consider the LOCALBASE environment variable; see the patch in the port collection.