...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!
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
Replaces SearchPathOptions::RuntimeLibraryImportPath with an equivalent std::vector of paths. Also reimplements SearchPathOptions::SkipRuntimeLibraryImportPaths to cause the list of runtime library import paths to be empty, rather than exiting early from SerializedModuleLoader::findModule().
When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
The previous 'openModuleFiles' interface in SerializedModuleLoaderBase
still assumed that swiftmodule files and swiftdoc files would be found
next to each other, but that's not true anymore with
swiftinterfaces-built-to-modules. Give up on this assumption (and on
the minor optimization of passing down a scratch buffer) and split out
the interface into the customization point
'findModuleFilesInDirectory' and the implementation 'openModuleFiles'.
The latter now takes two full paths: one for the swiftmodule, one for
the swiftdoc.
- Use the name for the cached module, so that we don't end up with a
zillion "x86_64-XXXXXXXX.swiftmodule" files in the cache when we're
working with architecture-specific swiftmodules.
- Diagnose if the expected name is different from the name specified
in the swiftinterface.
- Emit all diagnostics at the location of the import, instead of
without any location at all.
Previously these used the same "major architecture" names that the
`#if os(...)` query accepts, but that can be a problem when building
for, say, both armv7 and armv7s, even if the content is "the same".
For a transition period where external build tools are involved, the
compiler will look for "arm.swiftmodule" if it fails to find
"armv7.swiftmodule" or any other 32-bit ARM architecture. No other
Apple platform architectures are affected, and AFAIK no one's using
the architecture-based layout on Linux or any other platforms.
rdar://problem/45174692
This diagnostic needs to be adapted for swiftinterfaces too, but
meanwhile let's not have it get in the way when dealing with a
multi-architecture module that has parseable interfaces.
MyKit.framework/
Modules/
MyKit.swiftmodule/
x86_64.swiftinterface
x86_64.swiftdoc
# no x86_64.swiftmodule
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Added the 'Module::getPrecedenceGroups' API to separate precedence group lookup
from 'Module::lookupVisibleDecls', which together with 'FileUnit::lookupVisibleDecls',
to which the former is forwarded, are expected to look up only 'ValueDecl'. In particular, this
prevents completions like Module.PrecedenceGroup.
Before:
module file's minimum deployment target is iOS 12.0:
/path/to/FooKit.swiftmodule
After:
compiling for iOS 11.0, but module 'FooKit' has a minimum deployment
target of iOS 12.0: /path/to/FooKit.swiftmodule
Also tweak the "incompatible target" error to include the module name.
rdar://problem/35546499
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
Previously: "module compiled with Swift 4.1 cannot be imported in Swift
4.1.50" (i.e. following the -swift-version flag)
Now: "module compiled with Swift 4.1 cannot be imported by the Swift
4.2 compiler"
I'm pretty sure this is what I intended to do all along, and I just
messed it up when I originally implemented it. This is especially
important when working with downloadable toolchains, which would say
"module compiled with Swift 4.2 cannot be imported in Swift 4.1.50",
which is not really the problem at all. Now it'll fall back to the
more generic "module file was created by an older version of the
compiler" error.
Introduce a command-line option to visualize the complete set of output
request dependencies evaluated by a particular compile action. This is
exposing existing visualization facilities to the (-frontend) command line.
This can only happen in one case today: a module imports a bridging
header, but the header on disk has disappeared, and now we need to
fall back to the (often inadequate) version that's stored inside the
swiftmodule file. Even if the module fails to load, the bridging
header has already been imported, and so anything else that happens
might still emit diagnostics and need that text to be alive, which
means we need to keep the buffer alive too.
This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
When running Swift from within LLDB, we need to bypass resilience since LLDB
does not support resilience yet. However, the bypass was done too early as
part of the module loader, which had the effect of disabling resilience
altogether.
We still want resilience at the SIL level so that function types lower the
same with debugger support turned on and off. Only IRGen needs to bypass
resilience, so that LLDB can calculate fragile layouts of types. Also, the
DebuggerSupport flag is not always set in the ASTContexts created by LLDB.
So replace it with a new flag that only controls this behavior and nothing
else, and make it part of IRGenOptions to make it totally clear that it only
impacts IRGen.
Together with the paired LLDB change, fixes <rdar://problem/38719739>
and <rdar://problem/38483762>.
This turns all resilient types into fixed layouts thus allowing LLDB
to query their size. The long-term plan is to use remote mirrors for
this unformation instead of swift IRGen, but the library is not yet up
to the task.
rdar://problem/36663932
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
We use this to avoid circularity issues in serialization; we'd like to
extend that to the Clang importer. This is only necessary because we
can't look up a single member at a time, but it can still fix issues
in the short term.
This commit should have no effect on functionality.
People were getting confused when it said "module compiled with Swift
3.1 cannot be imported into Swift 4.0" when they were passing
"-swift-version 3".
rdar://problem/32187112
Follow Clang's lead in defining /System/Library/Frameworks and
/Library/Frameworks as default framework search paths. I'm doing this
manually rather than adding them to the actual list of search paths
because Clang will /also/ do this by default, and I don't want to
needlessly duplicate that work.
rdar://problem/31126655
This is like a single-threaded variant of the "lost wakeup
problem" that's all too common to anyone who's worked on
concurrent code.
When we perform lookup into a nominal type, we check if the
ASTContext's generation number is different than a cached
generation number in the nominal type. If the two numbers
differ, we walk over all loaded module files, telling them
to load any serialized extensions. Then we update the cached
generation number in the nominal type to record the fact
that we loaded any outstanding extensions.
The idea is to avoid unnecessary work if we know that no new
extensions have been added since the last name lookup.
The "bottom half" here is that when we add a new serialized
module file, we increment the ASTContext's generation number,
and then add an entry for the module file to a list.
The problem was that in between incrementing the ASTContext's
generation number and adding the module file, we would do some
work involving the ClangImporter which could in turn trigger
name lookup, which would "see" the new generation number in
the ASTContext, but not the new thing that is about to be
added, because it hasn't been added yet. So the
NominalTypeDecl's cached generation number would move forward
and the subsequent add of the module file would be "lost".
Specifically, it looks like when SerializedModuleLoader::loadAST()
calls loadedModuleFile->associateWithFileContext(), which does
some crazy ClangImporter stuff I don't understand, which in
turn can trigger a name lookup.
The fix appears to be to bump the generation number *after*
calling associateWithFileContext().
I don't completely understand what went wrong. For example,
this was dependent on the order of 'import' statements in the
input file. Of the two test cases I added, one the first one
triggered the problem -- the other test case is identical,
except the two import statements are transposed. I'm adding it
to ensure we avoid regressing in this case also.
Also I suspect it is possible to construct a test case that
does not depend on Objective-C interop or Foundation, but
again this looked tricky and I don't think the additional test
coverage on Linux would be worth the effort.
Fixes <rdar://problem/30817732>, so RxSwift now builds again on
master. Yay!
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
