It’s looking increasingly likely that Firefox will, in the not-too-distant future, build with a single C++ compiler across the four major platforms we support. I’m uneasy with this, but I think I’ve made my peace with it, partly as a result of writing the piece below.
Firefox currently builds with three major C++ compilers across four platforms: Microsoft’s Visual C++ compiler (MSVC), GCC, and Clang. A fair amount of work has been done to deal with peculiar bugs in all three compilers: you can go search the source code and/or Bugzilla to find hacks that were needed for one reason or another. A fair amount of work has also been stalled or shelved because one or two compilers don’t quite measure up in some required area (e.g. standards support). As you might imagine, many a Firefox engineer has bemoaned the need for cross-compiler compatibility.
Cross-implementation compatibility is something that Mozilla expends a lot of effort on in a different context. We have a Tech Evangelism bugzilla component for outreach to sites who use techniques that don’t translate across browsers. When new sites appear that deliberately block Firefox (whether because the launch team took the time to test with Firefox and determine the user experience wouldn’t be acceptable, or because cross-browser compatibility was an explicit non-goal), Firefox engineers go find the performance cliffs and fix them. Mozilla has a long-history of promoting the benefits of multiple implementations of the web platform; some of the old guard might remember “Works best in all browsers” campaigns and the like. If you squint properly, you can even see this promotion in the manifesto (principles 2, 5, 6, 7, and 9, by my reckoning).
So as nice as a single implementation might be, dealing with multiple implementations was a fact of life in building an high quality open-source browser. We dealt with it, because it seemed like we would always need to support MSVC; who would invest the time to create an open source, MSVC-compatible compiler?
Well, Google, mostly, and a host of other people, because the past several releases of Clang have included an MSVC-compatible frontend, clang-cl. (Indeed, Firefox has been using clang-cl for Windows static analysis builds for some time.) And now that we have a usable non-MSVC compiler on Windows, we can contemplate using an open-source compiler to create our release Windows builds. And once we have that, we can consider using (and potentially only supporting) a single compiler (Clang) for all of the major platforms we support; Linux would be the remaining holdout. (Chrome already ships on Windows with clang and requires clang everywhere, FWIW.)
We might continue to require that things build with MSVC and GCC on relevant platforms, even if we’re not shipping these builds; even if this happened, such builds seem unlikely to last for very long, for all the reasons that we wanted them dropped in the first place. I imagine we’d probably continue to accept patches to make things build with non-Clang compilers, as long as the patches were not intrusive, just like we accept patches for non-tier 1 platforms.
Supporting a single compiler has a number of advantages:
- Cross-language LTO (i.e. inlining) between Rust and C++ (we could, of course, do this today, but we wouldn’t get the win on all platforms);
- Mozilla engineers can fix bugs in Clang/LLVM if need be;
- Fixes can be more easily backported from the Clang/LLVM development tree;
- Contributors have fewer compiler quirks to hold up their patches;
- Integrating and/or upgrading local copies of upstream projects becomes easier;
- Performance tuning becomes somewhat more straightforward when you have a single compiler to worry about.
I am probably forgetting some along the way. (I don’t think it’s true that we’ll be able to entirely eliminate hacks to pacify the compiler; you push on C++ hard enough and long enough, and you find yourself doing all manner of unusual things. We might even find ourselves doing more hacks, since we can justify it via, “Since we can/can’t rely on the compiler to do X…”)
I can see all the advantages. I can even admire the sheer coolness of some of them; cross-language inlining sounds fantastic! But the analogy between the Web situation and the C++ compiler situation makes me uneasy: we ask web developers to write cross-browser compatible websites, with all the time and energy that requires. We tout the goodness of supporting multiple implementations of the web platform. However, in the implementation of that web platform, we are in the process of deciding that the benefits of supporting a single C++ implementation are greater than whatever benefits (engineering, philosophical, etc.) might accrue from supporting multiple implementations.
To be explicit: we are making the exact style of decision that we ask web development teams not to make.
(I’m not completely at ease with calling the two situations dissimilar; it’d be all too easy for a website to say they only care about a single “user”, viz. users of $BROWSER, and dispense with cross-browser support. I want to have a stronger argument for this case, but I don’t at the moment…)
At the end of the day, I think I’m mostly in support (0.6 on the Apache voting scale?). I think it will be cool when it’s done, and I will probably wind up doing some work in support of the project. But I can’t completely shake my uneasiness. What do you think?