Hmm. I went through the thread and could not find an answer to the question - why? Using platform's default compiler would be the safest thing to do and MS is making good progress with VC as far as adding standards support goes. They have been receptive of bug reports and relatively quick at fixing them too as far as I remember. Switching to clang also takes away the nice VS IDE based debugging experience [turns out it doesn't, I misread the post as saying you can still compile and debug with VS].
So what is Chromium gaining from switching to clang-cl? Perhaps just less amount of compiler specific code/hacks/quirks/workarounds etc?
Edit: This being Google I was expecting interesting data or at least somewhat thorough reasoning. The post just felt like a fyi for switching to clang. Nonetheless some good possible reasons in below replies.
Not having to worry about language feature support across different compilers is a big win. See https://bugs.chromium.org/p/libyuv/issues/detail?id=685 for one specific example of why using Clang can have benefits over MSVC (TL;DR: 64-bit MSVC doesn't support inline assembly). Clang was already being used to compile this little part of Chrome on Win64.
Switching to Clang also allows the use of Clang-based sanitizers and fuzzing, which improves the security of Chrome.
IIRC, Microsoft wants you to use intrinsics because it plays better with their register coloring and code reordering optimizations.
Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.
Your code won't be appreciably faster than if you tuned it in the compiler, and after a few years the compiler will integrate new instructions while your assembly just gets stale.
> Unless there's an instruction you need that doesn't have an intrinsic or you're writing something like a spin lock where instruction ordering is critical and a compiler barrier for some reason is not sufficient, there's no reason to ever write assembly.
So there are reasons to write code in assembly language.
There are few reasons to use assembly, and even fewer to use inline assembly
Using CPUID is one, using very specific vector instructions another (but you can do most of this using intrinsics) and it's better if they get their own .s file
> So what is Chromium gaining from switching to clang-cl?
There are lots of good reasons, but my favourite point -- besides considering clang to be a superiour c++ compiler in general -- is that using an open-source compiler allows us to fix things.
When a developer runs into a miscompile or compiler crash, finds an inefficiency in the generated code or has an idea for a new warning, we can fix it and push a new compiler out within days. And in addition to the work we put in ourselves, we benefit from the huge amount of work put in by the wider llvm/clang community.
It leads to a better developer experience, and in the end a better product.
As far as I'm aware, there are no downsides to switching to Clang on Windows. Clang produces VS-compatible debug info, it's integrated perfectly fine into VS. In addition, you don't need a VS license to compile the desired 64-bit Windows binaries. In addition, the code generated is typically faster and smaller. They get to use new C++ features without waiting for a major VC++ release. They can hope to do cross compilation on an operating system with a filesystem that isn't outrageously slow. They can stop having to put in VS-specific warning disables and go with the GCC-Clang standard ones. Clang is also just faster to run in general. They get to use one compiler on every platform, and when they improve the compiler, it helps all of their platforms.
But on the other hand Microsoft's compiler, linker, headers, debuggers are tested together for the OS releases they support. clang-cl doesn't have that advantage. I guess Google is picking up clang-cl maintenance to make sure it remains compatible with various dependencies MS changes.
Microsoft endorses and works on clang-cl, though I wouldn't say they give it as much attention as their own compiler. As for compatibility, I don't think it's a huge issue, if they never changed the compiler again, it would probably still generate working binaries for the next decade, including PDBs.
According to the first post in the linked thread, the switch to clang is transparent enough that the VS IDE-based debugging experience still works.
My guess (not being a Chromium developer myself) is that this is an exercise in consistency across platforms - I can imagine that using the same compiler on all supported platforms makes the language features supported consistent and removes the risk of one compiler generating much worse output for the same code. But I'm just postulating, I don't actually know for sure.
Google is the original writer or significant contributor of these tools. So presumably they first get clang work properly on Windows, then port these tools to Windows, then profit.
If you live in an "all compiler warnings are errors" world, having two compilers where a bit of code can cause a warning in one compiler and not cause a warning in another compiler is really annoying.
And this is why the intersection area in the Venn diagram of "people that use -Werror" and "people that use multiple compilers" is labeled "people who are making their own lives difficult, for no obvious reason".
Yes, sure - any time different people will be getting different sets of warnings, -Werror (or equivalent) is just going to make your life harder.
You should always strive for zero warnings on all builds across all compilers. It's a realistic, achievable and worthwhile goal. But while pretty much all warnings are worth looking at, a much smaller set are worth breaking the build over. You're much better off (in my view) promoting those particular warnings to errors, and leaving the rest as-is.
Presumably end users who are compiling from source wouldn't want to enable -Werror though.
If you are an application developer and a compiler X gives warnings that compiler Y doesn't for your application, then ideally you should probably fix the warnings from compiler X. An end user probably doesn't care either way, they just want to compile the program without any issues.
Realistically, though, an end user doesn't compile anything these days. If you build Chromium from source you're at least half interested in tinkering with it.
Well certain Linux distros (Gentoo comes to mind) are designed to support their users compiling applications from source. Some users just want to be able to compile using -march=native, and aren't interested in fixing compiler warnings that they didn't introduce. I personally would hate it if I wanted to compile an application from source but -Werror stopped complication through no fault of my own.
Using fewer compilers has obvious benefits to the software development and production process. E.g. no need to fix code when a checkin from developer on Platform X breaks the build on Platform Y.
I'd be curious if it robs it of some benefits, though. The process you describe above sounds like it might actually be beneficial in an "antifragile" kind of way.
That is, there are benefits to be had by knowing you do work on multiple toolchains. Painful at times, but mainly in ways that make a better product.
I don't know how the Chromium project is set up, but another way to achieve that benefit is to require that succeed on all platforms before code can be checked in. Which you should probably do anyway.
They do that, but for the programmers it's still annoying (and a waste of time) to have patches rejected because some compiler on some platform behaves differently.
I'm basing this assessment mostly on my own experience and testing. In terms of performance difference, it can be hard to compare since Clang-compiled programs often run on Linux, and MSVC programs run on Windows, so it's difficult to factor out the perf differences due to the OS. However I have measured one of our programs running significantly faster in a Linux VM, compiled in Clang, running with Windows as a host OS, than the program compiled with MSVC running directly on Windows.
In addition, the analyses and optimisations performed by Clang are generally more sophisticated than by MSVC. See for example http://www.forwardscattering.org/post/51.
The only optimisation I know of that MSVC performs that Clang doesn't (in some cases at least) is autovectorisation of some maths functions: https://bugs.llvm.org/show_bug.cgi?id=23645
(Actually MSVC has a pretty effective link-time code gen option, that is often turned off by projects using Clang)
Will the reliance on recent msvcredist (Visual c++ redistributable) be gone too with the move to Clang?
Their 2015 (and later) tooling and runtime cannot be trusted anymore, they send home data like there is no tomorrow - as observed on Win7. It's the VC++ runtime, the dotNet runtime, the dotNet optimization process, VSCode, dotNetCore, etc all send data home with no opt-in or opt-out option. This doesn't happen on other operating systems.
Uh oh, I have been putting a lot of effort embedding Chromium with Qt (which does not AFAIK have a clang build). I am afraid this is really going to slow me down. I wonder how this will harm other developers using CEF [0] w/ MSVC.
Edit: Now that I think about it, the Qt stuff is all in shared libs, so less worried there. But with CEF, the C++ wrapper is statically linked. What is MSVC's linker's ability to consume clang objs and vice versa I wonder. If not an issue, maybe I'm just fine.
I did a CEF-based project last year. I didn't built Chromium myself; I used a pre-build copy, from Spotify I think. The CEF build process sets this all up for you, so I expect this is typical. So this should mean that provided the clang builds of Chromium look the same to the outside world as the VC++ builds of Chromium, there won't be a problem.
(It works well. The PDB files and the corresponding source code are available, so you can step through the Chromium code in Visual Studio and so on.)
CEF is built as part of your program using whatever compiler you're using. I don't know what the mechanics of it are... I assume it uses the Chromium stuff via an import library? I didn't look very closely at this aspect of it.
Right, but CEF uses cmake w/ msvc customizations IIRC. And the spotify builds do ship with the DLLs already built. I asked on the CEF forum just now, we'll see.
Qt5.9 comes with windows clang spec for qmake. Previously you could setup it on your own in windows and Linux wasnt probably that hard either. For OS X "clang" was always a default.
Clang targets webassembly, doesn't it? If so, does that mean it will soon be possible to browse the web with chromium running inside other browsers? That'd be fun.
So what is Chromium gaining from switching to clang-cl? Perhaps just less amount of compiler specific code/hacks/quirks/workarounds etc?
Edit: This being Google I was expecting interesting data or at least somewhat thorough reasoning. The post just felt like a fyi for switching to clang. Nonetheless some good possible reasons in below replies.