[cfe-dev] A question about modules implementation

[Srivastava, Sunil via cfe-dev]

Hi All,

I am seeing something unexpected with -fmodules. Is this intentional ?

If I include a file of one submodule, I see code for static initialization for global
variables of files of other submodules of the same parent module.

To take a standalone example, make a directory "HDR" with three files "A.h", "B.h" and
"module.modulemap" with the following contents:

A.h:
    struct AA { AA();};

B.h:
    struct counter {
      int v;
      counter() { v = 0; }
    };
    const counter junk;

module.modulemap:
   module TOP {
      module A {
        header "A.h"
        export *
      }
      module B {
        header "B.h"
        export *
      }
    }

Now take a main file, test.cpp, with just one line
    #include <A.h>

and compile it with 'clang -S -fmodules -IHDR test.cpp'

Since there are no object definitions in A.h, one would expect an empty file. But
we see code for static initialization of 'junk'.

So the question: Why is 'junk' being initialized in test.s ?

If modules A and B are not nested in another module "TOP", then this initialization
does not occur. However, even with this nesting, why should module TOP.B be initialized
when only A.h is being included?

Without -fmodules, we get an effectively empty file, as expected.

I realize that putting a definition (of junk) in an include file is not a good idea,
still, I am not using that include file. Why should I be penalized for files that I am
not using.

Note that with the test case above, even if I include <A.h> (or even <B.h>) in multiple files,
no multiple definition error occurs because the variable definition is a const. The only cost
of -fmodules is some extra initialization code, though with multiple instances of this
phenomenon it can become significant.

Now, if the variable definition is made non-const, -fmodules prevents me from including <A.h>
in multiple translation units. The poor-programming-practice in <B.h> prevents inclusion
of <A.h> in multiple TUs. That is much more serious than just some extra code.

I have tested this with current TOT on Linux x86. The module cache was empty before doing
the compilation in these tests.

Thanks

Sunil Srivastava
Sony Computer Entertainment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151212/b17f5c97/attachment.html>