Exciting to finally see the release! But the feature I was most interested in appears to have been pushed to 3.8. Namely, the addition of -fsanitize-trap=undefined (which will allow for some parts of UBSan to run at compile-time rather than adding run-time overhead and bloat).

(Also, I know many people are not terribly worried about the overhead and bloat—and, to be fair, it is pretty minimal—but, I'm a little obsessed with keeping things about as light and small as I can make them.) :P

Either way, great to see the new stuff (especially the additions to the the static analyzer and formatter)! Here's looking forward to 3.8!

Very exciting. Since the current rustc is based on a fork of llvm, when can we expect it to be part of the mainline llvm?

I believe what you're asking is when rustc will be using a stable, unpatched version of LLVM? Rust is always working to get its custom patches upstreamed, but as soon as it does it typically comes up with more. :) That said, most of Rust's custom patches are to do with performance improvements due to compile-time information that C and C++ have no equivalent to, so theoretically Rust could probably exist on a stable branch of LLVM with nothing but a performance hit (and this may actually be the case if there exist OS package managers which don't want to package a custom version of LLVM with their Rust distribution, though I don't know if any package repos actually go to this length).

Debian rustc package is built against Debian LLVM 3.6 package. All Rust tests do pass.

On FreeBSD, I've seen bugs in release builds using that approach. The compiler works, but the compiling doesn't.

> theoretically Rust could probably exist on a stable branch of LLVM with nothing but a performance hit

Do you mean compile-time performance or runtime performance?

Both, there's at least one commit that directly affects the performance of LLVM (improves caching, AIUI), and the patches that improve runtime performance will improve compile time too: the rust compiler is written in Rust and so benefits from the LLVM tweaks.

(However, I believe both are relatively small.)

Rust compiles just fine with llvm36 from FreeBSD ports.

Most likely they won't ever be merged. llvm's a compiler library and is used by a number of outside projects. For example, mono uses llvm in compilation as well.

Excellent. While we're on the topic, does anyone happen to know the status of LLD?

LLD has been redesigned. LLD as released in 3.7 can link itself faster than MSVC's LINK.exe at a factor of around 2x. It can correctly link some large projects like Google Chrome and LLVM itself but I'd still call it rather experimental.

Work is ongoing to support features like COMDAT folding.

Thanks for the update. :) I know that the folks in the Rust project are curious about LLD's potential to provide a linker that Just Works on any of the platforms they target.

I think I could link faster than MSVC's LINK.EXE.

> Clang 3.7 includes an implementation of control flow integrity, a security hardening mechanism.

I wonder which operating system/Linux distribution will be the first to activate this by default when building binaries. It's extremely effective in preventing memory unsafety bugs to get exploited without a big performance hit.

I don't really understand why important targets like x86/x86-64 and ARM don't appear at all in the release notes. It seems unlikely that no work at all was done for them...

The MIPS and PowerPC folks were simply much better about writing release notes.

The BPF target looks promising for writing seccomp filters. Anyone tried it?

Nice to see references to LDC and LLVMSharp in the release notes.

Finally, official OpenMP support!