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
- Enhance SILBuilder::emitStrongRelease to be smarter.
- Start using emitStrongRelease in type lowering, SILGen,
CapturePromotion (replacing its implementation of the
same logic), and MandatoryInlining (one more place)
- Rename the primitive createStrongRetain/ReleaseInst
instructions to lose their suffix.
- Now that createStrongRetain/ReleaseInst are not special
cases from the naming perspective, remove some special cases
from DeserializeSIL and ParseSIL.
Swift SVN r10449
(the same way alloc_box returns two) instead of returning a tuple.
This eliminates a ton of tuple_extract instructions, which just
bloat the generated SIL. This resolves rdar://15378135.
Swift SVN r10416
If given a SourceFile, only decls within that SourceFile will be serialized.
Decls within other SourceFiles are emitted using cross-references that refer
to the current module.
Known issues:
- External definitions won't be serialized by any source file. They probably
have to be serialized into /all/ of them.
- Nothing can actually /read/ a serialized partial-module yet. We need a
notion of a TranslationUnit that can contain both source and serialized
files, and we probably need loading to be more lazy.
Swift SVN r9978
ModuleID is compatible with IdentifierID, but uses 0 to mean “the builtin module”
and 1 to mean “the current module”. Anything else is a top-level module name,
as an identifier. As an implementation detail, 1 is now never a valid IdentifierID.
(0 remains “the empty string”.)
Using this, simplify the encoding of the owner of a conformance.
Swift SVN r9944
Also add serialization of resilience attributes: Fragile, InherentlyFragile
and Resilient. Serialize VTables before SILFunctions because it may trigger
serializations of non-transparent SILFunctions.
Update funcOrOffset and vTableOrOffset when a SILFunction or a VTable is
de-serialized.
rdar://15165644
Swift SVN r9926
- Introduce emitTupleExtract / emitStructExtract, which fold when their operand is a tuple/struct.
- Rename SILBuilder::createTupleExtractInst -> createTupleExtract, "Inst" isn't used as a suffix.
- Switch capture promotion and DI to use the new functions.
This trims 300 lines out of the stdlib.
Swift SVN r9897
In serializer, we pre-assign a value ID in order, to each basic block
argument and each SILInstruction that has a value.
In deserializer, we use LocalValues to store the definitions and
ForwardMRVLocalValues for forward-referenced values (values that are
used but not yet defined). LocalValues are updated in setLocalValue where
the ID passed in assumes the same ordering as in serializer: in-order
for each basic block argument and each SILInstruction that has a value.
We update ForwardMRVLocalValues in getLocalValue and when a value is defined
in setLocalValue, the corresponding entry in ForwardMRVLocalValues will be
erased.
rdar://15351123
Swift SVN r9884
We add two records in sil_block to specify a Vtable and its entry list. Two
records are also added in sil_index_block for mapping from name to ID and
from ID to bit offset.
Two functions are added to SerializedSILLoader: to look up a specific VTable
given the class name or to deserialize all VTables in all SILModules. The latter
is mostly used for testing.
We serialize a VTable if the class is fragile and deserialize it via
SerializedSILLoader::lookupVTable.
Swift SVN r9746
SILFunction is null.
When the input SILFunction is null, we create a SILFunction. A null input
SILFunction can happen when deserializing SILVTable.
Swift SVN r9736
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
The operator lookup cache already lived in SourceFile, but we need to be
able to look up operators on a per-SourceFile basis. Different files can
have different imports. The interface previously distinguished between
"no operator found" and "error", but none of the call sites were making
use of this distinction, and indeed some were misusing the return value
(Optional<SomeOperatorDecl *>). Now the lookup functions just return
operator decl pointers, which may be null.
Swift SVN r9668
Value witness markers note the location within a generic function
type's list of requirements where the value witness table will be
placed when calling a generic function with that type. It allows one
to get the same effect from walking the requirements of a generic
function that one would get from walking all levels of a
GenericParamList, with all archetypes of each generic parameter list,
along with all of the protocols to which each archetype conforms,
which SILGen and IRGen both do.
AST verification ensures that the property above holds; we're not
making use of it just yet.
Swift SVN r9509
We don't actually need to serialize these because they've already been
encoded in the VarDecl's type. However, we'll probably need to be careful
when pretty-printing these on the other side.
Also, be more precise about checking @class_protocol serialization --
before we'd accept any failure, not just rejecting the struct conformance.
Swift SVN r9356
specific to types. While we're at it, improve the diagnostic for when a decl-specific
attribute is applied to a type, or a type-specific attribute is applied to a decl.
Swift SVN r9268
of having a ton of ad-hoc bools in it. This allows us to consolidate a ton of
boilerplate, eliminating 250 lines of code:
17 files changed, 435 insertions(+), 662 deletions(-)
2) This eliminates the special case for weak and unowned attributes, which previously
didn't show up in Attr.def.
3) While we're at it, keep track of proper source locations for each attribute, and
use these to emit diagnostics pointing at the attribute in question instead of at
a funcdecl or the @ sign.
4) Fix axle attributes, which had vertex and fragment swapped.
Swift SVN r9263
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
