Use apple's version of clang to compile iOS targets by default

[michaeleiselsc]

In Xcode, Apple ships a closed-source version of clang, which in turn has a closed-source version of LLVM (it seems like Xcode 9's LLVM forks off of LLVM 5?). Apple's clang/LLVM generally includes stability enhancements that would otherwise potentially cause problems for developers. I'm not sure what the benefits are of using Rust's current LLVM, e.g. it can be newer than Apple's, but Apple's clang is a really safe bet and seems a good thing to use by default. Some of these platform-specific issues can manifest in weird and very difficult to diagnose ways, e.g. random restarts, that it would be good to save developers from.

We could just give users a bitcode file for them to compile with clang themselves (#35968), or maybe there's some way to have the user specify which version of clang they want.

[michaeleiselsc]

I guess we should probably add OS X targets as well

[comex]

I've never heard of something like random restarts being caused by compiler issues (especially for an unprivileged userland app!)… and I don't think stability enhancements are the main reason Xcode has its own LLVM fork. But there have been cases where features show up in Xcode's LLVM before LLVM trunk - such as the entire arm64 port, when it was originally developed, because Apple wanted to keep it secret that they were planning to ship arm64 devices. And since producing bitcode compatible with Xcode LLVM is desirable anyway due to #35968, I suppose it wouldn't hurt to always use it to compile... Still, I'm not sure it's necessary.

[alexcrichton]

@michaeleiselsc / @comex do y'all know what something like this would entail? Do we need to stop compiling code like libbacktrace and/or other C code as part of libstd? Is this purely as a code generator step? Or is this purely to align LLVM versions so the bitcode is compatible?

We don't actually use clang anywhere in rustc itself at build time, but we do use LLVM! The version of LLVM that Rust is using may be somewhat difficult to align with OSX's, however, as that means that we'd have to ship a version of rustc per Xcode, right?

[michaeleiselsc]

@comex I can't go too far into the details of what has been merged into Apple's clang/LLVM on this public channel for security reasons, but I'm happy to discuss privately. But an app I was working on got hit hard by random restarts in December 2016, and it's caused by a specific issue that open-source LLVM only fixed December 2017. When we moved from open-source LLVM to Apple's LLVM in December 2016, the problem was fixed.

[comex]

@michaeleiselsc I'd like to hear more to clarify what's going on. Can you email me at comexk@gmail.com? Thanks very much…

[comex]

Well, I had a chat with @michaeleiselsc, and what he's talking about is the real deal - there really was a stability patch in Xcode's LLVM that didn't show up in the open source version for a long time. I apologize for being skeptical. That said, considering how many other things use open source LLVM on iOS - including, say, Apple's Swift development snapshots, which you can use directly from Xcode - I'm still not sure if it's really necessary to do something hacky to access the system's codegen.

On the other hand, the most difficult requirement, aligning rustc's LLVM version with Xcode's, is separately desirable in order to properly support embedded bitcode, and it would have the side benefit of enabling LTO between Rust and C.

I'll probably write more about this when I'm less tired.

[michaeleiselsc]

@alexcrichton as a temporary solution, how risky do you think it would be to build 1.24.0 on my OS X machine with LLVM 6? Would it be more or less risky than using 1.25, which, correct me if I'm wrong, has LLVM 6 already?

[alexcrichton]

@michaeleiselsc I don't think we had any major bug fixes for iOS/OSX, so it should hopefully work roughly alright! If something in src/rustllvm (our C++ shims) doesn't compile you can probably just copy the current shims on master