As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
When swift dependency scanner first finds a binary module for a testable
import, verify if the module is built for enable-testing or not. If not,
keeps searching in case there is a second testable binary module in the
search path.
Previously, the first binary module will always be accepted by scanner
and rely on the importer to provide a good diagnostics. Now the scanner
will emit a warning before continue searching, so user understands why
the binary in the search path is not taken.
If a testable module is loaded from a non-testable import, ignore its
optional dependencies because the consumer should not use them. This
matches the behavior of the implicit build or the behavior how
forwarding module is created.
Follow-up adjustment for binary module selection in dependency scanning
time. If a testable binary module doesn't have an interface file, it
should be used even it might pull in more dependencies.
Teach scanner to pick and choose binary modules correctly based on if it
is testable import or not. Some situations that scanner need to be
careful when testable is involved:
* When it is a regular import, it should not import binary modules that
are built with -enable-testing, it should prefer interfaces if that is
available.
* When testable import, it should only load binary module and it should
make sure the internal imports from binary modules are actually
required for testable import to work.
If a testable import only find a regular binary module, dependency
scanner currently will just preceed with such module and leave the
diagnostics to swift-frontend, because the alternative (failed to find
module) can be confusing to users.
rdar://125914165
