As part of this, re-arrange the argument order so that
generic arguments come before the context, which comes
before the error result. Be more consistent about always
adding a context parameter on thick functions, even
when it's unused. Pull out the witness-method Self
argument so that it appears last after the error
argument.
Swift SVN r26667
Provide a special single-ObjC-refcounted type info for error existentials, and lower the existential box instructions to their corresponding runtime calls.
Swift SVN r26469
storage for arbitrary values.
A buffer doesn't provide any way to identify the type of
value it stores, and so it cannot be copied, moved, or
destroyed independently; thus it's not available as a
first-class type in Swift, which is why I've labelled
it Unsafe. But it does allow an efficient means of
opaquely preserving information between two cooperating
functions. This will be useful for the adjustments I
need to make to materializeForSet to support safe
addressors.
I considered making this a SIL type category instead,
like $@value_buffer T. This is an attractive idea because
it's generally better-typed. The disadvantages are that:
- it would need its own address_to_pointer equivalents and
- alloc_stack doesn't know what type will be stored in
any particular buffer, so there still needs to be
something opaque.
This representation is a bit gross, but it'll do.
Swift SVN r23903
Previously, we were not respecting the representation of the existential
metatype and were treating all existential metatypes as if the metatype
was a thick metatype. Instead now we properly grab the instance of the
class from the existential and then query the runtime for the
objc_class. This is done via the new entrypoint
emitHeapMetadataRefForUnknownHeapObject.
I also modified emitHeapMetadataRefForHeapObject to use
emitHeapMetadataRefForUnknownHeapObject instead of
emitLoadOfObjCHeapMetadataRef since the latter does not properly handle
tagged pointers. This bug was found on inspection when Joe and I were
talking about this change.
rdar://18841292
Swift SVN r23308
layouts. Introduce new SIL instructions to initialize
and open existential metatype values.
Don't actually, y'know, lift any of the restriction on
existential metatypes; just pointlessly burn extra
memory storing them.
Swift SVN r22592
Eliminate support code for lowering protocol_method instructions, and eliminate ExtraDataKind::Metadata, which is no longer needed now that SIL provides all the necessary type information at the call site.
Swift SVN r22451
This is necessary to be able to properly stash values with nontrivial lowerings, such as metatypes and functions, inside existential containers. Modify SILGen to lower values to the proper abstraction level before storing them in an existential container. Part of the fix for rdar://problem/18189508, though runtime problems still remain when trying to actually dynamicCast out a metatype from an Any container.
Swift SVN r21830
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
This mostly falls out from the metatype cast infrastructure, but we need to generalize some Sema and SILGen code to accept AnyMetatypeType. Concrete-to-existential metatypes will need more runtime checking that isn't implemented, so raise a 'not implemented' error on those for now.
Swift SVN r17798
Centralize the logic for figuring out what name to use for a class or
protocol in the Objective-C runtime. When the flag is enabled (it's
still disabled by default), use mangled names for all Swift-defined
classes, including those that are @objc. Note that the naming is
determined in the AST, because we're also going to use this logic when
printing an Objective-C header for Clang's consumption. The mangled
names will always start with _Tt, so they're easy to recognize and
demangle in various tools or, eventually, in the Objective-C runtime.
The new test (test/IRGen/objc_mangling.sil) is the only test of this
behavior at the moment. The other test changes are due to the
centralized logic tweaking the names of internal constants (_DATA_*,
_CATEGORY_*, etc.).
This is the majority of <rdar://problem/15506580>.
Swift SVN r15588
When projecting an existential into an opened archetype, bind the
archetype with metadata and witness tables extracted from the
existential. Tweak SILGen so that it doesn't destroy the opened
archetype value an extra two times.
Use an executable testcase to ensure end-to-end operation, because we
still don't have a parsable form existential projection to opened
archetype instructions.
Swift SVN r13755
Refactor the base PolymorphicConvention implementation to work using generic signatures and dependent types instead of GenericParamLists and archetypes, using an ArchetypeBuilder to produce representative archetypes as a convenience when we need to consider all of the requirements attached to a dependent type. In EmitPolymorphicParameters, map the dependent types into context to resolve the archetypes that should be bound in the body of the function.
Swift SVN r13685
This lets us share implementation with emitArchetypeMethodValue and easily generalize emitArchetypeMethodValue to work with concrete types.
Swift SVN r10941
Handle an indirect cast from a class existential, so we can cast class existentials to opaque archetype types. Fixes <rdar://problem/15313840>.
Swift SVN r10545
Greg indicated that objc_getProtocol only works if somebody actually reifies a protocol_t record for the protocol with the runtime, so we need to emit our own protocol_t for every Protocol* value we do a checked cast with. Hijack the ClassDataBuilder to also build protocol_t records.
Swift SVN r9420
Use objc_getProtocol to derive a reference to the Protocol* for each required conformance, then pass the array off to a to-be-written dynamicCastObjCProtocol(Un)?Conditional entry point that will do all of the conformsToProtocol checks.
Swift SVN r9397
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
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
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
When an existential's contained type is used as a generic parameter, unwrap the existential container and save its metadata and witnesses to be used as polymorphic arguments.
Our AST representation can't quite express the distinction between a type parameter being satisfied by the existential type itself from being satisfied by the existential's contained yet. I use a goofy heuristic where I assume a protocol type bound to a type variable with no requirements is satisfied by the protocol type itself; this covers all of the existing <T> (Slice<T>, T) cases that come up in the library, while enabling the <T:Foo> (T) cases. This hopefully addresses <rdar://problem/14470097> well enough to unblock library work until we get a solid AST representation of this difference.
Swift SVN r6352
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
Use the new swift_dynamicCastIndirect runtime functions to implement casts from opaque archetype and existential types to concrete types.
Swift SVN r5684
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
Provide a lowering for the DeinitExistential instruction to deallocate the buffer in an existential container with an uninitialized value, using its deallocateBuffer witness.
Swift SVN r5623
Provide TypeInfo for class-bounded existentials, which represents them as an explosion comprising one witness table per subscribed protocol and then the class instance pointer as an ObjC-refcounted pointer. Provide lowerings for the SIL instructions that manipulate class-bounded existentials (except for existential-to-existential erasures, which aren't critical to getting basic operations working and will need some abstraction remapping to deal with class-bounded-to-opaque upcasts aside from the representation change).
Swift SVN r5579
Represent protocol 'P.metatype' types using the type metadata of the contained metatype. Emit 'typeof' value witnesses for protocol types that project the existential container buffer and then call the 'typeof' witness for the contained value. Implement the SIL protocol_metatype instruction the same way.
You can't quite call static methods on protocols yet because protocol_method doesn't know how to look up static methods from an existential metatype yet.
This breaks references to protocol names—they will try to create an existential metatype that refers to the metadata of the protocol type itself, rather than to the metadata of a conforming type. <rdar://problem/13438779> would fix them.
Swift SVN r5033
