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
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
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
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
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
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
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
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
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
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
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
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
Iff an enum declares a raw type, its cases may declare raw values or else have them assigned to them implicitly by autoincrementing from zero, like in C. If the raw type is float-, string-, or char-literal-convertible, there is no autoincrement, and the raw values must all be explicit. The raw type is rejected if any cases have payloads.
We don't yet diagnose duplicate raw values. That'll come next. We also don't yet serialize or deserialize the raw values. We don't strictly need to do this, since the RawRepresentable protocol conformance will be exported from the module as API, but Jordan pointed out that, for fragile raw values, this would be good for documents/jump-to-definition purposes, so we have a plan for only serializing the literals without having to deal with fully general expression serialization.
Swift SVN r8545
