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
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
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
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
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
1) on decls, they say the decl is weak/unowned.
2) in sil mode, on types, they indicate that the type has weak/unowned storage.
Since these are different things, split the SIL type attributes out to new
attributes (sil_weak/sil_unowned) to crystalize the relationship.
Swift SVN r9270
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Replace the existing suite of checked cast instructions with:
- unconditional_checked_cast, which performs an unconditional cast that aborts on failure (like the former downcast unconditional); and
- checked_cast_br, which performs a conditional pass and branches on whether the cast succeeds, passing the result to the true branch as an argument.
Both instructions take a CheckedCastKind that discriminates the different casting modes formerly discriminated by instruction type. This eliminates a source of null references in SIL and eliminates null SIL addresses completely.
Swift SVN r8696
Doug pointed out that 'isObjC' incorrectly excludes C functions, for which we'll also need to be able to independently reference Swift and foreign entries.
Swift SVN r8669
We generate a module from .sil, then deserialize the module using
sil-link-all.
Fix serialization and deserialization of CopyAddrInst.
Fix serialization of ProjectExistentialRefInst.
Add registration of ReferenceStorageTypeLayout, which we forgot to register.
We now have testing coverage of 70+ SILInstructions.
Swift SVN r8635
Add serialization/deserialization of the following SILInstructions:
BuiltinFunctionRefInst, IndexRawPointerInst, ModuleInst,
Conversion instructions:
RefToObjectPointerInst, UpcastInst, CoerceInst, AddressToPointerInst,
PointerToAddressInst, ObjectPointerToRefInst, RefToRawPointerInst,
RawPointerToRefInst, RefToUnownedInst, UnownedToRefInst
DestroyAddrInst, LoadInst, StrongReleaseInst, StrongRetainInst,
TupleElementAddrInst, TupleExtractInst
Make getModule in ModuleFile public to be used by SILDeserializer, also
make addModuleRef in Serializer public to be used by SILSerializer.
Update testing case to cover the above SILInstructions.
Swift SVN r8372
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).
This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.
In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)
Swift SVN r7698
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This should include all of the attributes we care about for the time being.
Only the resilience attributes (not designed) and [force_inline] are left
unaccounted for.
Swift SVN r6767
Previously, cross-references used a simple access path to refer to values
in other modules, but extensions have no name. They also accidentally
picked up values in extensions anyway, because lookupDirect includes
members in extensions. Now, we filter out values that don't come from
the referenced module, which may not be the same module the base type
comes from.
Swift SVN r6301
Classes are exactly like structs except that they may have a base class.
However, this type will show up in the inheritance list. That means we
don't actually need to serialize it twice; we can just grab the base class
from the inheritance list.
Swift SVN r6133
...in a quest for completeness. ArrayTypes don't actually work yet
(single-dimensional arrays are typed as slices), but when they do the test
that is currently XFAIL'd should start passing.
With this, all non-transient types can now be serialized and deserialized.
Swift SVN r6101
Instead, special-case cross-references to use the empty identifier as the
name of the Builtin module. This way imported modules will be able to use
builtin types and functions without the main TU having access.
Swift SVN r5947
When loading a module, we now try to load its dependencies as well.
If one of those dependencies can't be loaded, we emit an error message.
Swift SVN r5796
Like everything else, there are several caveats: no generic params, no
attributes, and (for now) no arguments. Pattern support is coming next.
Swift SVN r5701
The only tricky thing here is that the calling convention enum needs to be
stable in the module format, so it's marshalled in and out by helper
functions when crossing serialization boundaries.
Swift SVN r5699
Unlike Clang, Swift's DeclContexts are not all Decls. However, I believe
each DeclContext that is /serialized/ will be either a decl, a
TranslationUnit, or a FuncExpr for a function with an actual declaration.
This might turn out to be wrong if (a) SIL needs proper DeclContexts for
variables in function bodies, or (b) we need to serialize anonymous
closure default arguments.
Along with an extension of the ConstructorDecl placeholder code, this allows
us to round-trip empty structs.
Swift SVN r5532
This matches the behavior for compilation, and lets us test modules that
don't need any extra codegen.
With this, typealiases of builtins can be used end-to-end in modules!
Swift SVN r5326
...but don't do anything with them yet. This does check that they're being
correctly serialized, though.
This introduces a new ADT, PointerIntUnion, which like PointerUnion is an
efficient variant type using the lowest bit of data as a discriminator.
By default, the union can store any pointer-bits-minus-one-sized integer,
but both the integer type and the underlying storage type can be
customized.
Swift SVN r5321
Just a starting point -- builtin types are serialized by name, and the
IdentifierType necessary to /refer/ to a typealias is completely skipped.
This should be enough to start working on deserialization, however.
Swift SVN r5320
We can bikeshed on this later, but for now we can use a very explicit
extension that has no chance of stepping on any existing extension.
Swift SVN r5239
This adds names to the other blocks and records in the file.
The tests now require llvm-bcanalyzer to run; please build that along
with 'FileCheck' and 'not'.
Swift SVN r5109
Alternately, "add a system of ridiculous overkill for bitcode record layout",
in the spirit of DRY over YAGNI. It /is/ much more concise than the LLVM way.
Use this to emit a sketch of Clang's PCH control block, although nothing's in
there yet besides "version 1.0" and the LLVM revision number; the latter is
more "proof of concept" than actually useful. We should figure out a good
way to identify trunk Swift compilers; this shouldn't be difficult.
Swift SVN r5107
