Add a comment to the ClangImporterDependencyCollector explaining that
the FileCollector is used by LLDB to generate reproducers and is not
involved in dependency collection in Swift.
For reproducers in LLDB, we need to collect module dependency
information coming from the clang importer. However, we cannot override
the dependency collector, like we do in LLDB, because its interface is
completely hidden in the clang importer. The solution is to pass the
FileCollector through the DependencyTracker.
When cross-compiling with a swift built for another target or when
building with a pure toolchain without the resource directory containing
host content, the modulemap required for Linux may not be found. In
such a case, we should also look for the content in the SDK if one is
provided. This improves the behaviour of `swiftc` for Linux with a
standalone SDK.
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
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. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.
This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.
rdar://50261171
This option stopped working when clang changed its default behaviour to
-fmodules-validate-system-headers; we now need to explicitly disable it
to preserve the behaviour of our flag.
rdar://problem/50908762
Previously 'isSystemModule()' returns true only if the module is:
- Standard library
- Clang module and that is `IsSystem`
- Swift overlay for clang `IsSystem` module
Now:
- Clang module and that is `IsSystem`; or
- Swift overlay for clang `IsSystem` module
- Swift module found in either of these directories:
- Runtime library directoris (including stdlib)
- Frameworks in `-Fsystem` directories
- Frameworks in `$SDKROOT/System/Library/Frameworks/` (Darwin)
- Frameworks in `$SDKROOT/Library/Frameworks/` (Darwin)
rdar://problem/50516314
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
Clang r357037 removed the VirtualFileSystem member of CompilerInstance,
using the VFS from the FileManager instead. Update Swift's ClangImporter
to match that change.
Previously, we would assert that there's a runtime resource dir
available, but then accept the possibility of no glibc.modulemap. We
should just do the same thing for 'no resource dir' as 'no module map'.
This reapplies four commits for the ClangImporter. They broke the build
on master because the associated commits on swift-clang's
swift-5.1-branch never made it to stable due to automerger woes. This
time I'll push everything through manually.
These are the commits being reapplied:
- a42bc62397 "ClangImporter: Share a module cache between CompilerInstances"
- 9eed34235b "ClangImporter: Adjust to r355777, PCMCache => ModuleCache"
- da8a1c57e8 "ClangImporter: Use the new CacheGeneratedPCH in Clang"
- 2134b17a20 "ClangImporter: Test that PCHs are actually cached in memory"
rdar://problem/48545366
This flag causes the generated PCH to be written into the in-memory
module cache. Every CompilerInstance that tries to read the PCH will
use it rather than reading a potentially-since-overwritten version from
the filesystem.
rdar://problem/48740787
(cherry picked from commit 236fc19121)
Share an in-memory module cache between Clang compiler instances to
maintain a consistent view of the implicitly-generated PCMs, protecting
against filesystem races. This cache is more robust after r355778.
Note that there are still potential races for PCHs; I'll fix that in a
follow-up.
rdar://problem/48545366
(cherry picked from commit bf0e9a70c6)
Upstream Clang renamed getPCMCache() to getModuleCache() in r355777,
stopped passing it the Preprocessor passing it directly to ASTReader
instead. Adapt to those API changes.
rdar://problem/48545366
(cherry picked from commit 131cff72b2)
This flag causes the generated PCH to be written into the in-memory
module cache. Every CompilerInstance that tries to read the PCH will
use it rather than reading a potentially-since-overwritten version from
the filesystem.
rdar://problem/48740787
