The problem was that clang is quite intertwined with LLVM IR. ABI is spread all over the place, both FE and BE. It was proving hard to get something the house optimizers/code generators would be happy with. So a more radical path was chosen — wiring clang's parser + ASTs to another C++ front-end's AST and then using the old IR generator to get all of the idiosyncrasies right for the target. It was wacky, but seemed to be half-way working when I left, such that major open source code was compiling.
The whole idea of taking just parts of clang/llvm reeks of a half-measure anyway. It's probably better to either keep the existing compiler stack, or cut it right out and put the secret sauce into LLVM as add-in modules.
You can definitely build obj and lib files and link them with files built by MSVC. That works well.
We also support putting DWARF debug info (the standard format) into the binaries, and the LLVM linker LLD will link them and you can debug the resulting program with the LLVM debugger LLDB (or GDB for that matter).
This blog post is announcing:
1. Using clang as a frontend.
2. Using C2 (MS compiler) as a backend.
What the LLVM community (IE not MS so far, but participation is of course, welcome)) has been building:
1. Using clang as a frontend
2. Using llvm as a backend
and even more specifically
1. Using MS Headers + MS Libraries
2. Using clang as a frontend
3. Using llvm as a backend.
(see blog.llvm.org/2014/07/clangllvm-on-windows-update.html for a 9 month old view)
Some of the mingw32 folks have been working on replacing #1 with non-ms stuff, but let's put that aside for the sake of this description )
Using clang as a frontend is where almost all of the ABI compatibility happens anyway (and where various developers have been focusing), so you end up with VC++ ABI compatible binaries whether you use C2 or not, if you/they use the pre-existing clang stuff.
Whether they are doing that (and then lowering llvm ir to c2 ir) , or if they've built an alternative IR generation with clang (IE generating c2 ir directly from clang), that they haven't released, is not clear.
If they've built something that generates C2 IR from clang, they would have had to write their own ABI compat, which would mean it may be different than the binaries clang would build.
(exception handling is also codegen'd by llvm, so exception handling could end up different, though of course, compatibility is the goal)