I am not sure if I didn’t make it clear enough. It is not enough to implement header units trivially. The trivial header units implementation is: when the build system saw an import for header, compile the header to header unit BMI and consume that BMI. It is suboptimal. The ideal implementation is that the build system should be able to build every directly imported or indirectly imported header to a header unit BMI and replace the inclusion of the header to the corresponding BMI. See the following case:
// bar.h
// no other includes
...
// foo.h
#include "bar.h"
...
// zoo.h
#include "bar.h
...
// use.cc
import "foo.h"
import "zoo.h"
...
With the trivial implementation, the build system would only build 2 header units, one for “zoo.h” and one for “foo.h”. Then problem happens. There redeclarations in the two BMIs, which will cause suboptimal build time performance. So the trivial support for header units is not enough.
And what’s worse is, currently, clang may only replace the header inclusion in GMF with the provided BMI in the command line. (this follows the decision from GCC implementors, who is not active now).
So the conclusion is, to make it work as expected, the build system needs to support header units non trivially and the clang itself need other works to make it. I do think this is not trivial and a huge amount of work.
Now, I find it is fine. We won’t have the problem if we forbids to load BMIs for named modules at preprocessing time. I commented this in: