A SpecializedProtocolConformance intentionally contains all of the
information we need to synthesize the type witnesses from the
underlying (generic) conformance. Do so lazily rather than eagerly,
because we won't always need all of them.
As a nice side effect, we no longer need to serialize the witnesses of
these specialized protocol conformances, so we can save some space in
the Swift module file.
Swift SVN r11303
That is, if we need a type MyIndex<T> to be a valid ForwardIndex, we should
be able to find it in the conformance for BidirectionalIndex, which inherits
from ForwardIndex.
<rdar://problem/15484898>
Swift SVN r11270
In doing so, make serialization more deterministic. It was depending
on DenseMap ordering for both type and value witnesses. Now, serialize
the witnesses in the declaration order of the requirements.
Swift SVN r11267
The only reason to do this was in case an extension adopted a compiler-known
protocol, but that has long ben taken care of by
ModuleFile::loadDeclsConformingTo.
Swift SVN r11224
There shouldn't ever be a reason to do this: if a conversion function is
ever selected by the type-checker, it's because the type the conversion
lives on was suggested by another constraint, which means we can do a
normal lookup for the conversion function.
This is actually the only thing being eagerly deserialized, so remove the
notion of eager deserialization altogether.
Swift SVN r11220
NominalTypeDecls and ExtensionDecls have a list of members. Rather than
eagerly populating that list when the nominal or extension is just referenced,
just include a pointer back to the ModuleFile, so that they can be
deserialized when we actually look into the decl. The design here is
general enough that we could do something similar with imported Clang decls.
Clang is even more lazy here: the on-disk representation is a hash table,
so lookup only forces deserialization of members with the same name. We
probably want that some day, but this might be enough to get by for now.
This is groundwork for loading partial ASTs, where eagerly deserializing
members leads to circular references we're not able to handle.
Swift SVN r11219
Also updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to get the ImportSearchPaths from the ASTContext’s SearchPathOpts, instead of directly from the ASTContext.
Swift SVN r11214
Added a new SearchPathOptions class to swiftAST, which will contain options like import search paths and the SDK path.
Moved the RuntimeIncludePath from CompilerInvocation into SearchPathOptions. For now, at least, the RuntimeIncludePath is handled separately from other ImportSearchPaths, since we can’t yet guarantee that RuntimeIncludePath is set up before we parse the ImportSearchPaths.
Added a SearchPathOptions member to ASTContext.
Updated findModule() in SourceLoader.cpp and SerializedModuleLoader.cpp to check RuntimeIncludePath after everything else if no module was found. (This matches existing behavior, which had RuntimeIncludedPath at the end of ImportSearchPaths.)
Swift SVN r11213
are not settable (like get-only ones). Set the 'isLet' bit in various
places, but not the particularly interesting or useful places yet.
Swift SVN r11121
Remove the initialize_var instruction now that DI fully diagnoses initialization problems. Change String-to-NSString bridging to explicitly invoke String's default constructor; it was the last remaining user of initialize_var. Remove dead code to emit an implicit default constructor without a body.
Swift SVN r11066
Since we don't have soft-failure yet from deserialization, it's helpful to
at least know where to start looking when something crashes. There are some
rough edges here but it should be much better than nothing.
This also pulls the list of record nodes out into a separate file, so that
we can avoid repeating it.
Example crash:
1. While reading from ./CTypes.swiftmodule
2. While deserializing 'CBool' (StructDecl)
3. While deserializing decl #26 (XREF)
4. Cross-reference to 'LogicValue' in swift
(don't worry, this is an example where I'm tweaking things)
<rdar://problem/14838332>
Swift SVN r11057
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
Allow archetype_method to look up a witness from a concrete ProtocolConformance record. This will allow generic specialization to apply to constrained generic functions independent of archetype_method devirtualization. <rdar://problem/14748543>
Swift SVN r10950
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
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
Existing uses use a "globalvar" kind. Add a new "rootinit" kind which
will be used for root initializers (i.e. init methods of structs, enums,
and root classes).
Swift SVN r10772
a FuncDecl. This makes it much more straight-forward for SIL passes to
introduce a new one - without doing name lookup in the builtin module!
Swift SVN r10694
Like GlobalAddrInst, but for SILGlobalVariables. These would become the same instruction when SILGlobalVariable can replace AST-level global references.
Swift SVN r10510
Instead of hardcoding Builtin.Word to be an alias for Builtin.Int64, make it its own type of abstract pointer width.
- Change BuiltinIntegerType's width representation to accommodate abstract widths.
- In the AST and in SIL, store values of the types as the greatest supported size for the abstract width (64 bits for a pointer).
- Add some type safety to the ([sz]ext|trunc)(OrBitCast)? builtins that they're used appropriately given the upper and lower bounds of the abstract sizes they're working with.
- Now that Builtin.Word is a distinct type, give it its own mangling.
- In IRGen, lower pointer-sized BuiltinIntegerType appropriately for the target, and truncate lowered SIL values if necessary.
Fixes <rdar://problem/15367913>.
Swift SVN r10467
