Changing module maps

Hi,

I’ve experienced a few situations where I’ve been changing a module map during development, or passing module maps to others to try, who then get mysterious warnings or errors, such as:

test.cpp:2:2: warning: missing submodule ‘_Builtin_intrinsics.intel.x86intrin’

[-Wincomplete-umbrella]

#include <x86intrin.h>

^ ~

1 warning generated.

Sometimes clang detects it, and issues a relevant warning. Other times it does not. (Perhaps due to a time tag being earlier?) The recovery is to delete the module cache manually.

Is there something we could do to better detect a changed module map, and perhaps even better, also automatically delete the prior module cache to avoid potential problems? Checksum/CRC the module map? Use size and file time?

Thanks.

-John

Have you looked at what we currently do? I think there is at least some effort to detect invalid compiled modules; could you see why exactly it is failing?

– Sean Silva

We do these things, but the checks are turned off by default for system
modules (to avoid stat'ing all the system headers on every compile). I
think there's a flag to turn on the checks even for system modules,
-fmodules-validate-system-headers I think?

Maybe we should flip the default, and make the unsafe behaviour opt-in? IDEs and build systems can also use -fmodules-validate-once-per-build-session to avoid unnecessary re-checking without making it hard to edit system module maps.

Hi,

I’ve experienced a few situations where I’ve been changing a module map
during development, or passing module maps to others to try, who then get
mysterious warnings or errors, such as:

test.cpp:2:2: warning: missing submodule
'_Builtin_intrinsics.intel.x86intrin'

      [-Wincomplete-umbrella]

#include <x86intrin.h>

^ ~

1 warning generated.

Sometimes clang detects it, and issues a relevant warning. Other times
it does not. (Perhaps due to a time tag being earlier?) The recovery is
to delete the module cache manually.

Is there something we could do to better detect a changed module map, and
perhaps even better, also automatically delete the prior module cache to
avoid potential problems? Checksum/CRC the module map? Use size and file
time?

We do these things, but the checks are turned off by default for system
modules (to avoid stat'ing all the system headers on every compile). I
think there's a flag to turn on the checks even for system modules,
-fmodules-validate-system-headers I think?

Maybe we should flip the default, and make the unsafe behaviour opt-in?
IDEs and build systems can also use
-fmodules-validate-once-per-build-session to avoid unnecessary re-checking
without making it hard to edit system module maps.

Do we know why it was put in with its current default in the first place,
and how much it actually speeds things up?

-- Sean Silva