When SWIFT_OPTIMIZED is not set, add a little extra memory debugging,
which doesn't seem to slow anything down noticeably and can be disabled
as needed.
This change only affects the CMake build because that's the only place
where SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS is supported already. We may
want to extend this to the Makefile build.
Swift SVN r13008
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
Swift SVN r12998
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
...which would of course prevent them from being used. Sadly, this includes
the one I just added, since I didn't actually test it against the original
project until now.
Add a regression test that all block shims have valid manglings without
any unmangled suffixes.
Swift SVN r12672
...which is used for the first argument to
+[NSAnimationContext runAnimationGroup:completionHandler:].
Also, use the existing shims for NSFileCoordinator's NSURL-taking blocks;
they are equivalent to the shims that take id.
We really need to figure out how to do this (a) more generically (i.e. all
id-compatible types are treated the same), and (b) on the fly for the more
esoteric block types.
<rdar://problem/15864611>
Swift SVN r12668
This change is as minimal as possible, which means leaving obsolete
functionality in place (e.g. StringByteData) and even keeping the
"NewString" name in many places. The obsolete functionality was useful
for testing my changes, but expect immediate cleanup commits
addressing all those issues to follow.
* All String bridging now happens in pure Swift code.
* Because String no longer owns an array of UInt8, some assumptions and
assertions are no longer valid. As a result, some code was deleted
and all the code that produces null-terminated strings had to be
rewritten
* test/Constraints/construction.swift had to have one test commented out
because it relied on an element of the String interface that I did not
port forward. It seems to me that this test should declare its own
types and not rely on the stdlib, if it's still valid.
* One test in /test/stdlib/Algorithm.swift had to be disabled pending
<rdar://problem/15736729> and <rdar://problem/15733855>
* This change revealed that test/Interpreter/repl.swift is sensitive to
type-alias names; I had to change a "NewString" to "String" there.
This may indicate a bug somewhere?
Swift SVN r11830
Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
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
Same deal as for opaque existentials--pre-instantiate a static witness table for one-witness-table types (the zero-witness-tables case is nicely handled by Builtin.ObjCPointer's value witness), and generate a vwtable using dynamic witness implementations for each different-sized container on demand as necessary.
Swift SVN r9850
The assign-with-copy operation on existentials is complex enough to be emitted as a function call, which is currently generated on-demand by IRGen for every existential layout. We can instead use the implementation out of the runtime. Provide entry points for zero, one, and any number of witness tables.
Swift SVN r9815
Metadata.cpp:1280:26: warning: zero size arrays are an extension [-Wzero-length-array]
const void *_witnesses[NUM_VALUE_WITNESSES];
^~~~~~~~~~~~~~~~~~~
Metadata.cpp:1366:12: note: in instantiation of member class
'<anonymous>::OpaqueExistentialValueWitnesses<0>::Container' requested here
/*size*/ Container::size(),
^
Metadata.cpp:1448:51: note: in instantiation of static data member '<anonymous
namespace>::OpaqueExistentialValueWitnesses<0>::ValueWitnessTable' requested here
return &OpaqueExistentialValueWitnesses<0>::ValueWitnessTable;
^
1 warning generated.
As an aside, putting a template argument in ALL_CAPS is kinda wierd.
Swift SVN r9787
Instantiate static value witness implementations for the common zero- and one-witness-table cases, which correspond to the "Any" type protocol<> and to single-protocol types. For protocol compositions, instantiate a value witness table that uses the layout information from existential metadata to perform the value witness operations.
Swift SVN r9752
Set up a metadata cache for existential type metadata. Instantiate existential metadata by first sorting the protocol list, so that it is order invariant, precomputing the overall witness table count and class constraint of the composition so it can be cached in the existential metadata.
We still need to implement value witnesses for existential containers in the runtime before this is complete. We can at least test the uniquing and flags computations at this point.
Swift SVN r9727
It'd be nice to eventually report some context information, maybe derived from the location info on the originating 'cond_fail' SIL instruction, but this is a start.
Swift SVN r9589
