Use a stricter module hash for modules as moving towards more explicit
modules. Previously, a normalized target triple without deployment
target is used as part of the module hash, with the assumption that
deployment target should not change binary module generated.
In reality, the binary module compilation also needs to provide the
typecheck for all interface to ensure the underlying C/ObjC module that
built with the correct deployment target does provide the interfaces to
pass typecheck. Using a stricter module hash can avoid the potentially
confusing error when importing the module.
This commit adds following to module hash to distinguish swiftmodules.
* Deployment target
* -application-extension
rdar://134301179
The decision to exclude `-Xcc -D` options from swift module hash
actually doesn't help to solve the problem. It wouldn't reduce the
module variants (or the number of swiftmodule build commands) because
the command-line also encodes all the clang PCM dependencies that do get
affected by `-Xcc` flags.
To avoid the false sharing and the nondeterministic build products,
include most of the `-Xcc` flags, except include search path, into swift
module hash.
rdar://132046247
When the swiftmodule is built with different clang importer arguments,
they can have the same module hash, causing them to be wrongly re-used even
they contains different interfaces. Add ReducedExtraArgs to the module hash to
disambiguate them.
However, some Xcc arguments, most commonly `-D` options do not affect the
swiftmodule being generated. Do not pass `-Xcc -DARGS` to swift
interface compilation to reduce the amount of module variants in the
build.
rdar://131408266
