The point of this flag is to avoid re-checking the whole SDK on every
build, since under many circumstances you can assume it hasn't
changed. That worked for Clang modules, but Swift cached modules also
end up with dependencies that shouldn't be updated.
rdar://problem/53279521
Apart from not having to write out the SDK path, this allows us to
properly distinguish system and non-system dependencies. (Well, as
properly as we were doing before this commit, i.e. whether something
comes from the SDK.)
Groundwork for rdar://problem/53279521
If we are installing a forwarding module to something in the prebuilt
cache, make sure to create the module cache directory if it doesn't
exist.
rdar://52964217
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems into a
single overlay file system, and using that. To make this possible, we
always initialize the file manager with an overlay file system. In the
clang importer, we then create a new overlay file system, starting with
the one coming from clang, and adding overlays from swift on top.
The motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
- Check the target triple at runtime to decide whether to use the fallback.
- Change isInResourceDir to actually check the resource dir.
- Use ArrayRef<std::string> instead of std::vector<std::string>.
Sometimes, if one module we tried failed, we would leave the dependencies from the previous check and fail a different module which would have succeeded.
This manifested as the prebuilt-module-cache-forwarding test testing the wrong thing, because it retained a mod-time based dependency in the prebuilt cache, which should have been hash based, and used it.
If there’s a `.swiftmodule` corresponding to the `.swiftinterface` we’re loading, but it’s out of date or otherwise unusable, still make it a dependency of the cached module.
The general assumption with cached modules is that, by virtue of them being in the cache, they have a more up-to-date view of the world than the adjacent compiled module. However, if a new `.swiftmodule` comes along that’s totally valid, we should consider it as having a newer view of the world than the cached one, so we should use it instead.
Fixes rdar://51959788
A dependency being removed is not a hard error, because the recovery step is to recompile the interface. That might fail because of the change in dependencies, but that is a more actionable error.
Fixes rdar://51959698
...specifically, diagnosed in the parent DiagnosticEngine. This not
only provides a better user experience, but makes sure that the
compiler exits with a nonzero exit code even if the module goes
unused.
rdar://problem/50789839
This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
Although the default cache location separates by platform, a
/combined/ cache is still an interesting idea, and in that case we
need to use the full platform names.
If we're loading a .swiftmodule from the resource dir adjacent to the compiler,
defer to the serialized loader instead of falling back. This is mainly to
support development of Swift, where one might change the module format version
but forget to recompile the standard library. If that happens, don't fall back
and silently recompile the standard library -- instead, error like we used to.
rdar://49926152
- Fix a typo in the debug output for finding a prebuilt module
- Don't add the prebuilt module path to the dependency tracker
- Ensure we're registering the _forwarding module_'s dependencies in
cached modules, not the prebuilt module's dependencies.
- Check for the existence of a prebuilt module before doing the
is-up-to-date check (which will have failed anyway if it didn't exist).
- Test that forwarding module dependency collection works
rdar://48659199
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
Previously, the ParseableInterfaceModuleLoader relied on the assumption
that, if it returned `errc::not_supported`, it would fall through the
search paths and then move on to the SerializedModuleLoader. This did
not anticipate the possibility of a valid .swiftinterface coming later
in the search paths, which can cause issues for the standard library
which is in the resource-dir and should always be loaded from there.
Instead, make the module loading explicitly short-circuit when seeing
`errc::not_supported`, and document it.
Also add some more logging throughout `discoverLoadableModule` so we can
more easily catch issues like this in the future.
Fixes rdar://49479386
Dependencies in the SDK have their paths serialized relative to it to allow the
produced swift module to stay valid when the SDK moves. In the windows build
mixed slashes were coming through in these paths and breaking the check for
whether a dependency was in the SDK or not.
This patch ensures both paths are using native path separators prior to the
comparison to hopefuly fix the Windows build.
We previously added dependencies to the tracker inline while validating a cached
module's dependencies were up to date. If one of its dependencies ended up being
out of date though, we shouldn't have added the previous dependencies, as that
means the dependency list itself was also out of date.
This patch changes the behavior to only add the module's dependencies once we've
verified they're all up to date.
This patch modifies ParseableInterfaceBuilder::CollectDepsForSerialization to
avoid serializing dependencies from the runtime resource path into the
swiftmodules generated from .swiftinterface files. This means the module cache
should now be relocatable across machines.
It also modifies ParseableInterfaceModuleLoader to never add any dependencies
from the module cache and prebuilt cache to the dependency tracker (in addition
to the existing behaviour of not serializing them in the generated
swiftmodules). As a result, CollectDepsForSerialization no longer checks if the
dependencies it is given come from the cache as they are provided by the
dependency tracker. It now asserts that's the case instead.
*Their* dependencies are already being serialized out, so this shouldn't affect
up-to-date-checking except by alowing the regular and prebuilt module caches to
be relocated without invalidating their contents. In the case of the prebuilt
module cache, this gets us closer to supporting relocation across machines.
Updates the subinvocation that builds the parseable interface to respect the
-track-system-dependencies flag of the top-level invocation if present, by
including system dependencies in the produced .swiftmodule.
In addition to being wasteful, this is a correctness issue -- the
compiler should only ever have one view of this file, and it should not
read a potentially different file after validating dependencies.
rdar://48654608
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
A ‘forwarding module’ is a YAML file that’s meant to stand in for a .swiftmodule file and provide an up-to-date description of its dependencies, always using modification times.
When a ‘prebuilt module’ is first loaded, we verify that it’s up-to-date by hashing all of its dependencies. Since this is orders of magnitude slower than reading mtimes, we’ll install a `forwarding module` containing the mtimes of the now-validated dependencies.
