Before this change we had two different ways to attempt to locate the
sysroot which are inconsistently used:
* get_or_default_sysroot which tries to locate based on the 0th cli
argument and if that doesn't work falls back to locating it using the
librustc_driver.so location and returns a single path.,
* sysroot_candidates which takes the former and additionally does
another attempt at locating using librustc_driver.so except without
linux multiarch handling and then returns both paths.,
The latter was originally introduced to be able to locate the codegen
backend back when cg_llvm was dynamically linked even for a custom
driver when the --sysroot passed in does not contain a copy of cg_llvm.
Back then get_or_default_sysroot did not attempt to locate the sysroot
based on the location of librustc_driver.so yet. Because that is now
done, the only case where removing sysroot_candidates can break things
is if you have a custom driver inside what looks like a sysroot
including the lib/rustlib directory, but which is missing some parts of
the full sysroot like eg rust-lld.
dff8ee5b01