Given we're strongly against bundling libraries, not to mention the resulting build time, I don't really get why we default to using bundled LLVM.
It's not only disabled by default, it's also stable-masked.
There are multiple reasons:
1) Internal copy is often a bit older than system one. Currently it's llvm9. And this is what's tested.
2) Patching of rust often required to support new versions of LLVM. It can be quite problematic.
3) Rust's llvm copy contains number of codegen fixes / backports from llvm trunk.
4) with system-llvm users loose a bit of functionality. For example:
> rustc --print target-cpus
> Available CPUs for this target:
> native - Select the CPU of the current host (currently pwr9).
^ this and some other tight llvm integration only possible and works if using internal llvm.
on [system-llvm] rust this command will refuse to print CPUs.
5) It simply fails sometimes at codegen. It used to fail more often, we haven't encountered it for quite some time, thanks for upstream testing and local patching.
6) Build-wise, only libLLVM.so. sometimes LLD, but only for wasm. We don't install full llvm suite.
7) Tests sometimes fail with system-llvm. Testsuite is not enabled for users yet, needs more work filtering out meaningful tests and disabling what's useless for end-user.
Last 6 month there has been way less bug reports related to system-llvm, but I still think it's should not be the default. Yeah, bundling sucks, but in this case we loose functionality and maybe stability if we use system version. It's not like they bundle exact copy and results are exactly the same.
The rust llvm tends to have a number of fixes applied, we could try harder to have upstream to take fixes (like the one about the target list) and/or decide to carry them ourselves in our normal llvm.