The Swift entry point is required for the Swift metadata, while the
Objective-C entry point goes into the Objective-C metadata. As part of
this, stop emitting the destroying destructor for classes that use
Objective-C allocation: it won't work anyway.
Swift SVN r12199
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
In this revision, we profile the nested archetypes of each recursively, which I neglected to take into account originally in r12112, causing failures when archetypes that differed by associated type constraints were incorrectly collapsed.
Swift SVN r12116
IRGen type conversion is invariant with respect to archetypes with the same set of constraints, so instead of redundantly generating a TypeInfo object and IR type for Optional<T> for every T everywhere, key TypeInfo objects using an "exemplar type" that we form using a folding set to collapse together archetypes with the same class-ness, superclass constraint, and protocol constraints.
This is a nice memory and IR size optimization, but will be essential for correctness when lowering interface types, because there is no unique context to ground a dependent type, and we need to lower the same generic parameter with the same context requirements to the same type whenever we instantiate it in order for the IR to type-check.
Swift SVN r12112
In general, this forces SILGen and IRGen code that's grabbing
a declaration to state whether it's doing so to define it.
Change SIL serialization to serialize the linkage of functions
and global variables, which means also serializing declarations.
Change the deserializer to use this stored linkage, even when
only deserializing a declaration, and to call a callback to
inform the client that it has deserialized a new entity.
Take advantage of that callback in the linking pass to alter
the deserialized linkage as appropriate for the fact that we
imported the declaration. This computation should really take
advantage of the relationship between modules, but currently
it does not.
Swift SVN r12090
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
Use the 'thin' bit set by SIL to decide whether a metatype lowers to an empty type or not. In GenPoly we still need to accommodate unlowered metatypes to keep protocol witnesses limping along; hopefully that code can be killed soon. With this change we now lower @cc(witness_method) consistently for static methods.
Swift SVN r11535
In the fun case where you create an object of a non-ObjC-derived generic Swift class and hand it off as a DynamicLookup or other class existential, the first ObjC-like thing that happens to that object is that it gets sent the "release" message in the context that only knows of it as an ObjC object. It turns out this is bad; magic happens when the first class method is sent to an ObjC class. In the normal case this is +alloc, but in our case, Swift's runtime has instantiated a class and allocated an object completely independent of the ObjC runtime. To fix this problem and avoid similar problems in the future, emit a useless call to +class in the generic metadata fill function for generic metadata patterns to force this initialization. We should be able to roll this back when we properly register generic class instances with the ObjC runtime (<rdar://problem/15306370>). In the meantime, this fixes <rdar://problem/15674812>.
Swift SVN r11407
When we need a reference to protocol or protocol composition type metadata, ask for it through the runtime, instead of referencing statically-emitted protocol metadata.
Swift SVN r9871
Produce protocol descriptors when we see a protocol definition in the current module. If the protocol is @objc, go through the existing path for generating full Protocol* metadata for objc objects; otherwise, emit our layout-compatible but strong-external-linkage Swift protocol descriptor record.
Swift SVN r9867
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
Instead of trying to fill the superclass's generic parameter vector from the getGenericMetadata vector, which is broken, only populate the most-derived class's generic parameter vector from the getGenericMetadata vector, and copy the superclass vector from the superclass metadata.
Swift SVN r9301
In the fill function for a generic subclass metadata pattern, arrange to memcpy the field offset vectors from all of the ancestor classes into the newly-instantiated class metadata, before laying out the subclass's own fields.
Swift SVN r9299
In particular, when a nongeneric class inherits a fragile generic class, we need to populate the field offsets for the instantiated base class because we can't rely on the runtime to populate it for us.
Swift SVN r9258
When allocating and deallocating dependent generic class instances, load the instance size and alignment from the metadata instead of trying to use a static size from the compile-time class layout.
Swift SVN r9250
We need these for dependent-layout generic classes so we know the allocation/deallocation size and alignment. When I figure out ObjC interop with generic subclasses these should move to the rodata so they get handled resiliently by the ObjC runtime, but for generic class bringup this is convenient.
Swift SVN r9249
In the metadata template fill function for generic classes with dependent layout, include a call to a (not yet implemented) runtime initClassMetadata function to lay out the class fields and initialize the field offset vector.
Swift SVN r9233
The field's layout kind affects its own field access in addition to that of its following fields. This puts dependent fragile field accesses down the right code path. The NonFixedOffsets were inside us all along.
Swift SVN r9221
When we have fixed offsets available for fields, emit them into the metadata or metadata pattern. If we don't, emit zero and leave it for the pattern fill function to resolve at runtime.
Swift SVN r9114
Its job will be a bit more broad for generic structs, where it needs to fill field offsets into the metadata in addition to storing the final size, stride, and alignment information to the value witness table.
Swift SVN r9104
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
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
Share common FindValueTypeArgumentIndex and FindValueTypeWitnessTableIndex templates between the struct and union metadata versions of these scanners, templatized on the MetadataScanner they use. This makes witness table parameter lookup into generic union metadata work.
Swift SVN r8268
Teach a BoundGenericType to compute its own substitutions, which
allows AST clients to create new bound generic types without the aid
of the type checker.
This eliminates the TypeChecker::validateTypeSimple() abomination as
well as the need for the BoundGenericType AST validation step. There
is still more cleanup to do in this area.
Note that BoundGenericType::getSubstitutions() now accepts a module
parameter, which is the place from which we will look for
conformances. This is a baby step toward properly modeling the
conformances as part of the bound generic type, and is nowhere near
complete.
Swift SVN r8193
When loading a selector in the JIT, we need to call
sel_registerName(). This was manually coded in two places and missed
in a third, so factor it appropriately.
Swift SVN r8082
For dynamic generic types, this emits the sequence of operations to turn a value witness table template into a full, valid value witness table. For now, leave it stubbed out as empty, except for dynamic singleton unions, where we copy the size, flags, and stride from the lone element's table.
Swift SVN r8014
If a generic type has dynamic layout, the value witness table for its instances is dependent on its generic parameters for size and alignment. Instead of emitting a global symbol for the vwtable in these circumstances, embed the value witness table template in the generic metadata template so that both get instantiated in tandem by the runtime when the generic instance metadata is requested.
Swift SVN r7931
Factor out a UnionMetadataLayout and UnionMetadataScanner CRTP class, mirroring those for structs, and use UnionMetadataScanner to find generic parameters in union metadata.
Swift SVN r7918
Use EmitPolymorphicParameters to extract the metadata for generic type parameters from the "self" argument to value witnesses so that they're available to the value witness implementation. This makes it so that the compiler no longer crashes when emitting the value witness table for a generic struct with dynamic size.
This temporarily breaks generic unions since we didn't properly implement generic argument lookup for union metadata yet. Fix coming shortly.
Swift SVN r7910
To instantiate the value witness table for generic types, we were instantiating the generic type at () for all of its parameters and hoping for the best. That's insane. Instead, let's use the DeclaredTypeInContext for the generic type so the archetypes actually get usefully bound inside the witnesses. This way, the witness implementations should be independent of generic parameters, so we can also mangle the unbound type into the witness symbols.
Swift SVN r7901
Instead of hardcoding a walk of a list of fill ops, have generic metadata templates carry a pointer to a fill function for swift_getGenericMetadata to invoke to perform the fill operations. For types with dynamic layout, we will need to be able to perform more complex fill operations than a simple transfer of arguments into generic metadata slots.
Swift SVN r7893
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
