When building with implicit modules it's possible to hit a scenarioThis patch makes it an error to have a mismatch between the enabled
sanitizers in a CU, and in any module being imported into the CU. Only
mismatches between non-modular sanitizers are treated as errors.
This patch also includes non-modular sanitizers in module hashes, in
wheorder to ensure modules are rebuilt withoutds occur when -fsanitize=address, and are subsequentlyX is toggled on
imported into CUs with -fand off for non-modular sanitize=address enabled.rs, This can causeand to cut down on module rebuilds
strange failures at runtime. One case I've seen affects libcxx, sincewhen the option is toggled for modular sanitizers.
This fixes a longstanding issue with implicit modules and sanitizers,
its vector implementation behaves differently when ASan is enabledwhich Duncan originally diagnosed.
Implicit module builds should "just work" when -fsanitize=X is toggledWhen building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This causes strange
on and off across multiple compiler invocations.failures at runtime. The case Duncan found affects libcxx, This patch implements asince its
fix by including the set of enabled sanitizers in the module hashvector implementation behaves differently when ASan is enabled.
Sanitizers which cannot affect AST generationImplicit module builds should "just work" when enabled are not-fsanitize=X is toggled
included in the module hash.on and off across multiple compiler invocations, This will help cut down on module rebuilds.
AFAICT, all of this only applies to the implicit module build casewhich is what this