[Tooling] [isocpp-modules] Dependency format with module details implementation

Ben Boeckel ben.boeckel at kitware.com
Wed Apr 10 22:14:03 CEST 2019


On Wed, Apr 10, 2019 at 18:32:49 +0000, Gabriel Dos Reis wrote:
> It is not clear to me why we would want to have this apply to header
> unit.  By the definitions, they are not modules.  They don't have
> names other than the name of the header or header file.  They don't
> provide anything other than their content as a whole.  The only
> dependencies they have are exactly the same that their headers or
> header files have and therefore can be extracted via the usual
> pre-processing scan.  Why would their BMIs be required for
> dependencies?

I'm OK with this as well. However, GCC currently expects a BMI for
header units during compilation:

foo.h:

    const int foo = 0;

foo.cpp:

    import <foo.h>;

    int main(int argc, char* argv[]) {
        return foo;
    }

```
% g++ -fmodules-ts -std=c++2a -I. -o foo foo.cpp
In module imported at foo.cpp:1:1:
./foo.h: error: failed to read module ‘!/foo.h.gchm’: No such file or directory
./foo.h: fatal error: jumping off the crazy train to crashville
compilation terminated.
```

Using `"foo.h"` instead:

```
foo.cpp:1:8: internal compiler error: in module_state, at cp/module.cc:3221
    1 | import "foo.h";
      |        ^~~~~~~
We are damaged, This is broken.
Partial device,
Pliable design,
Hunt through the rubble for what once was.
See <https://gcc.gnu.org/wiki/cxx-modules#Bugs> for instructions.
```

--Ben


More information about the Tooling mailing list