Suppose module 'Foo' exists in the search paths and specifies user module version '1.0'.
If the first encountered 'canImport' query is unversioned:
...
Followed by a versioned one:
...
The success of the first check will record an unversioned successful canImport, which will cause the second check to evaluate to 'true', which is incorrect.
This change causes even unversioned 'canImport' checks to track and record the discovered user module version.
Teach dependency scanner to report all the module canImport check result
to swift-frontend, so swift-frontend doesn't need to parse swiftmodule
or parse TBD file to determine the versions. This ensures dependency
scanner and swift-frontend will have the same resolution for all
canImport checks.
This also fixes two related issues:
* Previously, in order to get consistant results between scanner and
frontend, scanner will request building the module in canImport check
even it is not imported later. This slightly alters the definition of
the canImport to only succeed when the module can be found AND be
built. This also can affect the auto-link in such cases.
* For caching build, the location of the clang module is abstracted away
so swift-frontend cannot locate the TBD file to resolve
underlyingVersion.
rdar://128067152
When caching build is enabled, teach dependency scanner to report
command-lines with `-direct-clang-cc1-module-build` so the later
compilation can instantiate clang importer with cc1 args directly. This
avoids running clang driver code, which might involve file system
lookups, which are the file deps that are not captured and might result
in different compilation mode.
rdar://119275464
Fix the ExplicitCASModuleLoader check for if `canImport` works for a
specific swift module. It was mistakenly using the clang caching schema
to load the underlying module but in reality, it should only load swift
module with swift caching schema.
In future, we should let dependency scanner to report version/underlying
version for the modules it enounters so the versioned canImport check
doesn't need to load and parse the module/TBD file to figure out if the
check is successful or not.
rdar://120554271
Improve caching related tests to make them faster and test the situation
closer to what actually happens during explicit module build. Most
noticable changes are:
* Avoid swift stdlib dependency during the tests to save time
* Use dependency scanner output to construct test cases
* Update old test cases that try to simulate caching from file system
inputs to using only CAS inputs.
Improve tests to call python script through python executable. Even this
doesn't cause any errors now, it will be a problem for future when we
run CAS tests on Windows platform. Clean up the current test to avoid
bad test example.
When clang submodule is used in `canImport` check, it should return the
top level module as dependency, not the submodule. This fixes a
regression after #70974 that causes dependency scanning to fail due to
failed submodule lookup during dependency scanning.
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
