Bitwise takability is now part of the layout of a type, because
non-bitwise takable types are never stored inline in an
existential or resilient global's buffer, even if they would
fit.
The basic rule is that weak references, unknown-refcounted
unowned references, and aggregates that contain them, are not
bitwise takable, whereas everything else is bitwise takable.
Also, since the bitwise takable for an unowned reference
depends on the reference counting style, we have to record the
superclass of a protocol, if any, to correctly determine the
reference counting style of the protocol existential.
We can use the extra inhabitants of the type metadata field as extra inhabitants of the entire
existential container, allowing `Any?` and similar types to be the same size as non-optional
existentials.
I stopped trying to guess and actually tested them all, including the
Apple-internal tool I keep breaking. As a bonus, the RUN lines in
validation-test/Reflection/ go back to being simple.
rdar://problem/44154961
- Hard-link %target-swift-reflection-test into %t/ for %target-run
implementations that copy executables, like remote-run.
- Use DYLD_LIBRARY_PATH to undo that for %target-run implementations
that run the executable in place (host and simulators)
rdar://problem/43809613
utils/remote-run will only run things in %t.
An Apple-internal tool doesn't follow symlinks.
Normal macOS and simulator runs find the support libraries relative to
the binary.
I'm not sure what to do yet, but for now let's unbreak the
Apple-internal bots I broke in 01a0de2.
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
