Tag build swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-05-a
Modules: Ignore diagnostic mismatches on validated modules

This is a minor update to bded4ae30659, to avoid erroring out when
trying to import a module whose diagnostics don't match, as long as it
has already been validated elsewhere in this process.  If it was
validated before, we should just use it.

The testcase, which Adrian helped me generate, does the following:

  - Assume two modules:

     1. Mismatch, which is not marked as a system module.

     2. System, which *is* marked as a system module.  It imports

  - When imported on its own, Mismatch will be considered a "user"
    module; inside of System, Mismatch will be considered a "system"

  - With a cold cache, build the following translation units:

     1. Generate Mismatch as a user module with -Wno-system-headers
        (the default).

            @import Mismatch; // Built.

     2. Import Mismatch and generate System with -Wsystem-headers.

            @import Mismatch; // Imported in place.
            @import System;   // Built; needs to import import Mismatch.

The diagnostic validation for the direct import of Mismatch in (2)
doesn't care that -Wsystem-headers has been turned on, because it won't
affect how Mismatch (a user module) is treated.  However, the build of
the System cares that Mismatch was built without -Wsystem-headers, since
now Mismatch is being re-interpreted as a system module.

To support this change, I've restored the previous behaviour of checking
the signature for new modules inside ModuleManager::addModule.  We need
to be sure that the checks in ASTReader::findAndReadUnhashedControlBlock
aren't letting mismatched signatures slip through (since that will
trigger a rebuild in the *importing* module).  Without this change,
test/Modules/outofdate-rebuild.m spews ASan errors.
6 files changed