zturner

It’s extremely difficult to get new keywords into the language. This is a very large part of the reason we can only have new functionality in the library.

More precisely:

clang-cl is a drop-in replacement for cl (even the command lines are the same).

But clang-cl is just a driver for clang, and it's still possible to get the ABI compatibility without clang-cl, but you have to know what you're doing and get the flags right.

This sounds great, it's been a long time coming and I'm sure many people will appreciate being able to debug their mingw generated executables in Visual Studio.

I did all of the PDB stuff in LLVM, happy to help if you need it (ping me on the mailing list or IRC)

1) ABI compatibility is not present. With clang-cl you can compile half of your object files with MSVC and half with clang-cl, and link them together. That's very powerful. You might be thinking "but who is really gonna do that anyway?" However, there is more to the ABI than just this. For example, consider what happens if you need to use Structured Exception Handling. Well, with GCC, you can't.

2) Debug Information. GCC does not emit PDBs, it emits DWARF. This means you cannot use Visual Studio to debug, you cannot use vTune or WPA to profile, you cannot use symbol / source servers.

3) There are licensing implications, GPL != BSD and it's easier to use BSD.

These are the main reasons. There are other reasons though, such as if the entire goal is to get down to 1 toolchain and that toolchain is X, then why would you waste your time converting Y to Z?

This is incorrect. FlushFiewOfFile and FlushFileBuffers only guarantees that contents are written to the physical media. It is not necessary (well, it is not supposed to be necessary) to call either of these functions for other processes to be able to see the changes.

The whole point of a cache is that if A writes something, and then B reads it after A finishes writing it, B should see the results of A's modification. Whether it has been flushed to the physical media is irrelevant, because if it hasn't the cache manager can still serve the contents directly from the cache. And a call to Flush is not necessary for that.

So, the OP's change is not missing anything. As the article explains, it is in fact the Windows kernel that is behaving incorrectly (which was also confirmed by people who work on the windows kernel).

Minor implications, perhaps. Much of what was done to reach this point was just making LLDB not fall over miserably on Windows. Like, to compile.. Or to not crash on startup for example :)

Anyone who decides they're interested in making Rust programs debuggable with LLDB will be able to benefit from this work by not having to do it. Also a core debug loop is going to be the same on Windows no matter what programming language is being debugged. I don't know what Rust's generated code looks like, but presumably it will be able to reuse the core debug loop and symbol reading code to some extent, although it will need to deal with ABI specific differences, put in its own expression evaluator, and things like that.

TL;DR - Someone from the Rust community will still have their work cut out for them, but if they're so motivated then they at least some of the work done here will benefit them.

The LLVM project as a whole has many contributors from many different companies working on things they care about and contributing it back to the community.