accessors.
Optimize these accessors by making them check for
BoundGenericXType instead of BoundGenericType and dyn_cast'ing
the Decl. (The latter used to be necessary before we split
BoundGenericType.)
Swift SVN r15037
LLVM doesn't have interior symbols as a first-class concept, so generate module inline asm that defines the OBJC_CLASS symbol relative to the Swift metadata symbol. To prevent our system linkers from considering this symbol as the start of a new object and breaking apart class metadata objects, put the class metadata object into a no_dead_strip section.
This isn't quite enough to get the OBJC_CLASS symbol to be available--the symbol appears to show up in the .o as an undefined symbol and stripped out of the .dylib. John is investigating with the backend and linker teams as to why this is the case.
Swift SVN r14927
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
Make IRGen just a little bit dumber: rather than inferring whether we
need the Swift or Objective-C metatype based on the uses of that
metatype, produce the metadata in the representation requested by the
'metatype' or 'class_metatype' instruction. SILGen will eventually
need to get smarter about asking for the representation it wants.
Swift SVN r14117
This has the nice "side effect" of making overrides of generic
functions work better, fixing the remaining type checker issues from
<rdar://problem/15836098>.
Also synthesize the types for derived RawRepresentable conformances
directly rather than going through the type checker, so we get the
interface types right.
Swift SVN r14066
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
Calling +class on our generic classes is not enough to reliably realize a generic class instantiation; if the method is already hot in the shared metaclass's cache, it will bypass the actual realization of the instance. Try another hack to force the runtime to realize the class by invoking class_getInstanceMethod on it, which appears to work more reliably. Factor the hack out into a runtime call so we can tweak it more easily in the future. This gets <rdar://problem/15898373> and <rdar://problem/15898701> working.
Thanks DTrace and John for helping puzzle out what was going on here.
Swift SVN r12934
This lets IRGen avoid emitting an alloca for common generic metadata instantiations. These entry points can also be marked "readnone", and the general getGenericMetadata entry point can be "readonly", giving LLVM's optimizer a fighting chance on unspecialized generic code.
Swift SVN r12789
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
It was convenient to just assume that the SILModule defines
the deallocating destructor function. This should probably
be represented somehow in e.g. the sil_vtable instead of
being an implicit dependency.
Swift SVN r12412
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
