This was failing alongside inherits_ObjCClasses.swift (they were failing at the
same time).
Until MikeA has time to look at this disable this as well.
rdar://problem/50898688
In anticipation of potential future HW features, e.g. armv8.5 memory
tagging, only use the high 4 bytes as discriminator bits in
_BridgeObject rather than the top 8 bits. Utilize two perf flags to
cover this instead. This requires shifting around a fair amount of
internal complexity.
Implements SE-0229.
Also updates simd module types in the Apple SDKs to use the new types, and updates a couple tests to work with the new types and protocols.
We now have plenty of extra inhabitants in the variant enum, so we can get rid of the 7-bit hack.
It’d also be possible now to increase small string capacity to a spacious 11 bytes; however this needs a full overhaul of the 32-bit representation, so it needs a little bit more time in the oven.
Previously, they would forward their unused spare bits to be used by other multi-payload enums, but
did not implement anything for single-payload extra inhabitants.
The standard library never ended up needing the low extra inhabitants (<4G on 64-bit Darwin,
<4K elsewhere), so BridgeObject can have the same set of extra inhabitants as the other refcounted
types, allowing `String?????` and `Array??????????` to still use optimized representations.
rdar://problem/45881464
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.
Like we did for structs, make it so that tuple types can also get extra inhabitants from whichever element with the most, not only the first. This lets us move all of the extra inhabitant handling functionality between structs and tuples in IRGen up to the common RecordTypeInfo CRTP base.
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
Copy %target-swift-reflection-test into %t instead of using a hard
link. The problem with hard links is that they can be overwritten when
the test fails, which would then truncate the original executable to
an empty file!
- 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".
Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
We would lay out all classes starting with a Swift-style two-word header, even classes that inherit NSObject and therefore don't have Swift refcounting. The ObjC runtime would slide our ivars down for us at realization time, but it's nice to avoid unnecessarily dirtying memory in the not-uncommon case of direct NSObject subclasses.
For generic multi-payload enums, we would proceed down the
dynamic layout path without checking for a builtin descriptor.
As a result Set and Dictionary were always reported as being
9 bytes in size and not 8. Oops...
Fixes <rdar://problem/30066015>.
There were a few problems here with subclasses of Objective-C classes.
Use the InstanceStart field from rodata to correctly lay out instance
variables, and verify the results match with dynamic and static layout.
Better fix for <rdar://problem/27932061>.
Some of these are kinda dubious, but I think this would be better
addressed as part of eager bridging, which will invalidate the concept
most of these are checking for.
