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 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
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
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
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
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
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
Simplify/clarify a condition that was attempting to avoid a particular
circularity: the value type of a NominalTypeDecl for type T is T.metatype.
Normally, we use the type of a value decl to verify that we actually have
the thing we want (and in the case of functions, to pick a particular
overload). In this case, however, trying to deserialize a reference to
T.metatype ends up just trying to deserialize T again -- it's not in our
lookup table because the deserializer isn't yet sure it's the /right/ T.
The existing code avoided this with a hack: check if the ValueDecl's type
is a metatype. The new code actually does the right thing and checks for
a TypeDecl.
Swift SVN r9038
Put generic nominal type declarations through the same dependent-type
validation as generic functions, then capture their generic parameters
and requirements in their generic signature. This allows us to
re-instate the requirements in their dependent forms, before the
archetypes ruin them completely.
Swift SVN r8958
Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
When type checking, allow the caller to customize the resolution of generic
type parameter types based on the context, for example, by choosing to
substitute in an archetype (or not) and allowing one to resolve a dependent
member reference via a specific archetype.
No actual functionality change here.
Swift SVN r8797
Instead of relying on the subpattern being a well-formed TuplePattern, let's track our own subelements so we can associate them to properties and validate them ourselves.
Swift SVN r8771
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 a SILLinkage mode "Deserialized" to make sure IRGen will emit
hidden symbols for deserialized SILFunction.
Inside SIL linker, set Linkage to external if we only have a declaration for
a callee function.
Both sil block and decl block in a module can emit an array of substitutions.
To share the serialization between SILSerializer and Serializer, we modify
the interface to pass in the abbreviation codes to write functions and to
pass in a cursor to read functions.
We now correctly handle the serialization of Substitutions in SpecializeInst.
For a deserialized SILFunction, we now temporarily set its SILLocation and
DebugScope to an empty FileLocation. Once mandatory inliner sets the SILLocation
to the location of ApplyInst, a null SILLocation and a null DebugScope
may work for a deserialized SILFunction.
Update testing cases to reflect that we are now inlining transparent functions
from modules, or to disable SILDeserializer for now (I am not sure how to update
those testing cases).
Swift SVN r8582
