Move to a custom build of Clang 6.0.1

[DHowett-MSFT]

This pull request moves WinObjC to Clang 6.

• All commits labelled C6Compat were changes required to build the project.
• All commits labelled NFC are not final/not-for-checkin.
• The directory LLVM/lib contains upstream vendored files.

Fixes #2837, #2806, #1647, #405, #2341, #1140, #160.
Closes #1769.

---

This change is 

[DHowett-MSFT]

This pull request also breaks ARM support.

[DHowett-MSFT]

Fixes #2837 #2806 #1647 #405 #2341 #1140 #160.
Closes #1769.

[DHowett]

TODO: Include patches in tools/msvc/patches, but don't package them.

[MSFTFox]

Why the custom build of clang 6? I thought the intention was to move away from having our own binaries here.
Edit
I realized this is probably an intermediate step as our proposed changes get merged with official binaries. There's no reason for us to halt changes blocked on outside dependencies.

[MSFTFox]

Whoah.... Quite the fallbacks here. What are the ramifications of this? Did we severely spike which packages we require to contribute to Islandwood by including all these now? I'm all for manipulating NuGet if it helps us unblock certain troublesome scenarios but a giant list of all these frameworks seems strange in the least.

[edvv]

Exciting stuff!!

[DHowett-MSFT]

This is copied from Nugetizer-3000's default template, and is required so that package target lookup doesn't fail during restore. It doesn't add any additional dependencies!

[DHowett-MSFT]

We have clang changes that may never be suitable for upstreaming; our compromise is to upstream what we can and provide patches for what we can't.

[wjk]

I have a question about this PR. I noticed that the MSVC-derived binaries in the LLVM/bin folder (mspdb*, c2.dll, etc.) have been removed. Having watched Clang's upstream development, I know that their MSVC compatibility (and, in particular, their ability to generate and manipulate PDB files) is much improved over where it was just a few years ago. Furthermore, @DHowett-MSFT's comment about "clang-6.0.0+ms" implies that we are moving to upstream(-ish) Clang instead of a heavily modified, Microsoft-specific fork. Should this PR be merged, will it mean that the Clang compiler used will be open-source (or, at least, can be replaced with a self-built Clang and not cause too much breakage)?

Even though WinObjC was never really suitable for its intended purpose IMHO, I still think it has some interesting ideas under the hood that I might want to extract and use in my own projects. (In particular, I was thinking of adding support for the Mac frameworks — AppKit et al — as well as the iOS ones, and creating a macOS-to-Windows app bridge.) Should the Microsoft-proprietary compiler be finally removed, this would greatly aid the implementation of these ideas.

Thanks for answering my question, and keep up the good work! 😄

[DHowett-MSFT]

Hi @wjk!

That's a very astute observation. We're planning on upstreaming any Clang changes that make sense and switching to an upstream build at our earliest convenience. For now, though, we have patches staged for upstreaming in issue #2860, and the ones that haven't made it up will be included in this pull request.

I'm very interested in your plan to support Mac frameworks. Would you mind e-mailing me at duhowett@microsoft.com to continue this conversation?