If a child process crashes outside of a test context, the parent process
should signal test failure. This behavior is a sign of something bad
happening in the child (for example, memory corruption), and should not
go unnoticed.
Child processes were exiting too early before the parent has a chance
to read a null pointer from the child, indicating that there are no
more instances to reflect. This wasn't a problem on OS X because the
I/O latency is so small compared to the iOS simulator, where the
problem would come up under heavy load. This makes the end-to-end
remote mirror tests deterministic again.
rdar://problem/26230879
... as well as new test collection types:
`MinimalRandomAccessCollectionWithStrideableIndex` and
`DefaultedRandonAccessCollectionWithStrideableIndex`, to test default
implementation of `index(...)` family of functions provided by the
standard library for the random access collections with strideable
indices.
Also add end-to-end tests for this finally, and fix a bug in
the SwiftReflectionTest library where we would give up on an
module completely if it did not have a field metadata section.
This is of course wrong if the module defines closures but
not nominal types.
Previously, the callback for objc_setUncaughtExceptionHandler
took a parameter of type 'AnyObject!', which was implicitly
unwrapped at all uses inside the closure. When that became
'AnyObject?', we started getting an extra layer of Optional in
the printed output.
This reverts the tests to their pre-4d540c2a state.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
Implement the ReflectionContext's implementation of:
swift_reflection_projectExistential.
First, we get the type info of the existential typeref - it should be a
record type info. If it's a class existential, it has trivial layout:
the first word is a pointer to the class instance. Otherwise, if the
value fits in the 3-word buffer of the existential container, it
trivially is also at the start of the container. Otherwise, the value is
off in a heap box somewhere, but the first word of the container is a
pointer to that box.
