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
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
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
Move the uniquing information for ForeignTypeMetadata behind the address point so we can share the layout between foreign classes and the existing layout for struct and enum metadata. Emit metadata records for imported structs and enums as foreign metadata candidates, and dynamically unique references to the metadata by calling swift_getForeignTypeMetadata.
Swift SVN r23081
As a stopgap till IRGen properly emits indirected class references, support direct class reference protocol conformance records. This should get us to the point we can replace the dlsym hack with the new implementation.
Swift SVN r23073
We should unique foreign struct/enum metadata the same way we do CF foreign class metadata, but for now, treat them as direct references like we do in IRGen.
Swift SVN r23072
If for some reason an eliminated dead method is called (e.g. because of a compiler bug),
then the application aborts with a readable error message.
Swift SVN r22990
When we emit a witness table, build a protocol conformance record for it, and emit the list of all conformance records into a "__swift1_proto" section of the data segment.
Swift SVN r22939
existential (and existential metatype, and unowned
class existential) values when checking for extra
inhabitants. We don't guarantee the meaningfulness
of these bits.
Fixes rdar://17431105, where this showed up as
affecting correctness in debug vs. optimized builds.
Swift SVN r22608
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
Storing the root protocol outside the potential archetype meant we
could easily have forgotten to pass the right argument to
PotentialArchetype::getType(). Our current staging of archetype
construction means that nothing go it wrong today, but it's a minor
minefield for future improvements to the archetype builder.
Swift SVN r22504
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 was a harmless bit of unnecessary work until John added "materializeForSet" witnesses for protocol requirements, which never exist in @objc protocols. Fixes rdar://problem/18428904.
Swift SVN r22244
Fixes crasher #003 (rdar://problem/18232605). This time, also increase the buffer size for the necessary bindings so we don't clobber memory.
Swift SVN r22118
- A spot fix in SILGen for reabstracting the result of a downcast, which fixes checked casts to function types.
- Associate the layout information in type metadata records with the most abstract representation of the type. This is the correct thing to do in cases where we need the metadata as a tag for an opaque value--if we store a value in an Any, or pass it as an unconstrained generic parameter, we must maximally reabstract it. This fixes the value semantics of existentials containing trivial metatypes.
- To ensure that we get runtime layout of structs and enums correct when they contain reabstractable types, introduce a "metadata for layout" concept, which doesn't need to describe the canonical metadata for the type, but only needs to describe a type with equivalent layout and value semantics. This is a correctness fix that allows us to correctly lay out generic types containing dependent tuples and functions, and although we don't really take advantage of it here, it's also a potential runtime performance win down the road, because we could potentially produce direct metadata for a primitive type that's layout-equivalent with a runtime-instantiated type. To aid in type safety here, push SILType deeper into IRGen in places where we potentially care about specific representations of types.
- Finally, fix an inconsistency between the runtime and IRGen's concept of what spare bits unmanaged references and thick metatypes have.
Together, these fixes address rdar://problem/16406907, rdar://problem/17822208, rdar://problem/18189508, and likely many other related issues, and also fixes crash suite cases 012 and 024.
Swift SVN r21963
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
We were stopping too early when binding witness tables for local archetypes, causing us to miss binding witness tables for native protocols if the number of total protocols was greater than the number of protocols with witness tables, and we failed to increment the local type data key to match the Archetype::getConformsTo() ordinal when binding polymorphic parameters. Together these fix rdar://problem/18232916 (though adding any methods to a class still crashes because of rdar://problem/17480006).
Swift SVN r21796
I introduced a function swift_keepAlive2() which has a different signature from
swift_keepAlive() until I can verify that the stdlib is using the new
infrastructure.
The difference in signature is that swift_keepAlive2 takes just a pointer while
swift_keepAlive also takes a metadata value that is not necessary for our
purposes anymore.
Swift SVN r21718
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
We were accidentally picking out the instance pointer for the witness table in the packed enum payload representation. Fixes <rdar://problem/17857154>.
Swift SVN r21026
initializeBufferWithTakeOfBuffer value witness.
Attempt to use initializeBufferWithTakeOfBuffer in
some appropriate places.
There are some changes enabled by this which are
coming in a follow-up patch.
Swift SVN r20741
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
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
