Due to a couple of unfortunate circumstances, appending an NSArray instance to an Array instance does not actually append any elements.
The cause is https://github.com/apple/swift/pull/29220, which accidentally optimized away the actual loop that appends the elements in this particular case. (And only this particular case, which is why this wasn’t detected by the test suite.)
When the argument to `Array.append(contentsOf:)` is of type NSArray, the `newElements is [Element]` expression is compiled into a runtime check that returns true, eliminating the subsequent loop over the remaining items of the iterator. Sadly, NSArray.underestimatedCount` currently returns 0, so the earlier _copyContents call is a noop, so no elements get added to `self` at all.
Turning the `is` test into a direct equality check between the metatype instances resolves the issue.
- Remove references to swiftImageInspectionShared on Linux and dont have
split libraries between static/non-static linked executables.
- -static-executable now links correctly Linux.
Note: swift::lookupSymbol() will not work on statically linked
executables but this can be worked around by using the
https://github.com/swift-server/swift-backtrace package.
When assertions are enabled _endCOWMutation writes to _native.isImmutable.
But finalizeUninitializedArray is marked as @effects(readnone). This
mismatch caused miscompile in the stdlib due to CodeSinking optimization
which relies on SILInstruction::mayReadOrWriteMemory which looks at
@effects.
withUTF8 currently vends a typed UInt8 pointer to the underlying
SmallString. That pointer type differs from SmallString's
representation. It should simply vend a raw pointer, which would be
both type safe and convenient for UTF8 data. However, since this
method is already @inlinable, I added calls to bindMemory to prevent
the optimizer from reasoning about access to the typed pointer that we
vend.
rdar://67983613 (Undefinied behavior in SmallString.withUTF8 is miscompiled)
Additional commentary:
SmallString creates a situation where there are two types, the
in-memory type, (UInt64, UInt64), vs. the element type,
UInt8. `UnsafePointer<T>` specifies the in-memory type of the pointee,
because that's how C works. If you want to specify an element type,
not the in-memory type, then you need to use something other than
UnsafePointer to view the memory. A trivial `BufferView<UInt8>` would
be fine, although, frankly, I think UnsafeRawPointer is a perfectly
good type on its own for UTF8 bytes.
Unfortunately, a lot of the UTF8 helper code is ABI-exposed, so to
work around this, we need to insert calls to bindMemory at strategic
points to avoid undefined behavior. This is high-risk and can
negatively affect performance. So far, I was able to resolve the
regressions in our microbenchmarks just by tweaking the inliner.
The constructor `init?(text: Substring)` was more available than its
type Float16 for macOS and macCatalyst where the type is explicitly
unavailable. The compiler may report this as an error in the future.
On OpenBSD, malloc introspection (e.g., malloc_usable_size or
malloc_size) is not provided by the platform allocator. Since allocator
introspection is currently a load-bearing piece of functionality for
ManagedBuffer and ManagedBufferPointer, pending any API changes, as a
stopgap measure, this commit marks methods in ManagedBuffer and
ManagedBufferPointer calling _swift_stdlib_malloc_size and methods
dependent thereon unavailable on OpenBSD.
This may induce some compatibility issues for some files, but at least
this change ensures that we can get stdlib to build on this platform
until the evolution process addresses this problem more thoroughly.
* Dynamic Cast Rework: Runtime
This is a completely refactored version of the core swift_dynamicCast
runtime method.
This fixes a number of bugs, especially in the handling of multiply-wrapped
types such as Optional within Any. The result should be much closer to the
behavior specified by `docs/DynamicCasting.md`.
Most of the type-specific logic is simply copied over from the
earlier implementation, but the overall structure has been changed
to be uniformly recursive. In particular, this provides uniform
handling of Optional, existentials, Any and other common "box"
types along all paths. The consistent structure should also be
easier to update in the future with new general types.
Benchmarking does not show any noticable performance implications.
**Temporarily**, the old implementation is still available. Setting the
environment variable `SWIFT_OLD_DYNAMIC_CAST_RUNTIME` before launching a program
will use the old runtime implementation. This is only to facilitate testing;
once the new implementation is stable, I expect to completely remove the old
implementation.
