Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
Also, erase empty entries from the map once they've been loaded, just in
case we end up registering /more/ buffers later.
No intended functionality change.
Swift SVN r25202
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
This isn't being used for much yet, but it will allow us to tell whether
something is an app target even at the module-merging stage, which is a
better way to tell if something is an app than whether it has a bridging
header.
We'll also need this if we ever take advantage of reusing "partial modules"
(serialized ASTs for other parts of the module that aren't affected by the
current source file) for compiling source files in incremental builds;
unfortunately that's unlikely given our dependency model.
Swift SVN r24531
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
This included a test that failed on case-sensitive filesystems. Test fixed.
(Aside: Why not just have this fail with "no such module"? Why use a different
error? Because even if "import FOO" picks up a module named 'Foo', there may
actually be a module named 'FOO' on the system (in another folder), and we
should be able to find that. Fixing that is tracked by rdar://problem/18691936.)
rdar://problem/15632996 (again)
Swift SVN r22856
Due to case-insensitive filesystems, "import foundation" can result in the
overlay module for Foundation being loaded. Everything is confused later on
because the (wrong) module name is used in manglings, leading to all sorts
of issues.
This is not the right fix for the problem, because a user really is allowed
to have modules named "foundation" and "FOUNDATION" and "Foundation" coexisting
on their system. To do that we'll want to check the actual case of a
.framework bundle or .swiftmodule file on disk and make sure it matches before
even trying to load the file. But this is a good sanity check anyway.
rdar://problem/15632996
Swift SVN r22818
Like the Clang decls, this happens at the end of the type-checking, just as
a simple walk through the loaded decls of the loaded modules. This caught
all of the issues in this commit series and will hopefully keep us honest in
the future.
(By the way, we don't verify right when we return a deserialized decl for the
same reason we don't verify right when we return an imported decl: parts of
the decl may be delayed, and (a) we don't want to force things to be imported
or deserialized sooner than necessary, yet (b) we want to verify as much as
possible.)
rdar://problem/16968891
Swift SVN r22200
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
This performs very conservative dependency generation for each compile task
within a full compilation. Any source file, swiftmodule, or Objective-C
header file that is /touched/ gets added to the dependencies list, which
is written out on a per-input basis at the end of compilation.
This does /not/ handle dependencies for the aggregated swiftmodule, swiftdoc,
generated header, or linked binary. This is just the minimum needed to get
Xcode to recognize what needs to be rebuilt when a header or Swift source
file changes. We can revisit this later.
This finishes <rdar://problem/14899639> for now.
Swift SVN r18045
Also, create the Clang module loader directly rather than indirecting through
a "get constructor" function. It's no longer a valid configuration to not
have a Clang importer.
Swift SVN r16862
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Swift can now find modules inside framework bundles matching this layout:
Foo.framework/
Foo.swiftmodule/
ARCH.swiftmodule
Currently, ARCH is the architecture name used by build configurations (#if),
but this was more done out of convenience than anything else (there's
currently no access to the current target from the ASTContext). We'll need
to revisit this if/when we decide to support architecture subtypes (armv7s
vs. armv7 vs. arm), at which point we'll also have to deal with fallback
architectures.
Framework search paths are specified using -F. Like bare import paths, there
are currently no "built-in framework search paths".
The master plan for Swift frameworks is in <rdar://problem/16062602>.
<rdar://problem/16155907>
Swift SVN r14363
This is necessary since if one wishes to write a secondary tool with swift
headers, one can not access the ModuleFile in SerializedASTFile since to do so
would require you to be a friend of the class, something that would create a
build dependency in between the secondary tool and the swift libraries.
Swift SVN r14171
From now on, /any/ changes to SIL or AST serialization must increment
VERSION_MINOR in ModuleFormat.h.
The original intent of VERSION_MAJOR/VERSION_MINOR was that VERSION_MAJOR
would only increment when backwards-incompatible changes are introduced,
and VERSION_MINOR merely indicates whether to expect additional information.
However, the module infrastructure currently isn't forgiving enough to accept
even backwards-compatible changes to the record schemas, and the SIL
serialization design might not be compatible with that at all.
So for now, treat any version number 0.x as incompatible with any other 0.y.
We can bump to 1 when we hit stability.
<rdar://problem/15494343>
Swift SVN r13841
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12921
Each loaded file gets added to the main module, rather than being a standalone
separate module. In theory, this will be used to assemble several partial
ASTs into a complete module. In practice, there's still a ways to go...but
this can already round-trip a single module file.
This also factors out the FileUnit-creating part of SerializedModuleLoader,
which should help clients like SourceKit that don't need to search for a
swiftmodule file associated with a particular import.
Swift SVN r10952
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
