Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231

[mdznr]

When initializing a Deque from an Array (coming from NSArray), it crashes at runtime with error:

Fatal error: unsupported: file Swift/ArrayBuffer.swift, line 231

Information

• Package version: commit 65a3841
• Platform version: macOS 11.2.1 (20D74)
• Swift version: Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
  Target: x86_64-apple-darwin20.3.0

Checklist

• If possible, I've reproduced the issue using the main branch of this package.
• I've searched for existing GitHub issues.

Steps to Reproduce

Crashes at runtime (Deque+RangeReplaceableCollection.swift:144):

let array = NSArray(arrayLiteral: NSString()) as! [NSObject]
let deque = Deque(array)

Runs without crashing:

let array = NSArray(arrayLiteral: NSString()) as! [NSObject]
let deque = Deque(Array(array))

Expected behavior

The first example above doesn’t crash.

Actual behavior

Only the second example doesn’t crash.

[lorentey]

Cc @atrick

Interesting; this is triggering this precondition in the standard library:

extension _ArrayBuffer {
  ...
  public __consuming func _copyContents(
    initializing buffer: UnsafeMutableBufferPointer<Element>
  ) -> (Iterator,UnsafeMutableBufferPointer<Element>.Index) {
    // This customization point is not implemented for internal types.
    // Accidentally calling it would be a catastrophic performance bug.
    fatalError("unsupported")
  }
}

Deque is merely calling the public withContiguousStorageIfAvailable method on the supplied argument -- this ought to be safe on all collections.

Note: the arrayLiteral initializer simply forwards to NSArray(array:). The NSString object is irrelevant -- this also reproduces with any NSObject:

let array = NSArray(array: [NSObject()]) as! [NSObject]
let deque = Deque(array) // 💥

It looks like verbatim-bridged NSArrays are currently broken in the stdlib.

[lorentey]

OK, so we'll need to ship a fix for this in the stdlib. It's a relatively straightforward oversight I think; it's a shame we haven't found it earlier.

let array = NSArray(array: [NSObject()]) as! [NSObject]
array.withContiguousStorageIfAvailable { _ in } // 💥

(The bug lied undetected for so long because withContiguousStorageIfAvailable is not that frequently used in production code. It's also not yet adequately covered by the stdlib's validation tests, so surprises like this are unfortunately possible.)

We probably also want to add a workaround to this package, preferably without disabling the use of withContiguousStorageIfAvailable altogether.

[atrick]

@lorentey Well I admit to being baffled by how these customization hooks are intended to be layered. I thought Sequece._copyContents was only supposed to be called on array objects in the fast path when the source is already contiguous. But it looks like lazy bridging code violates my understanding of layering in multiple places.

In this case, it looks like NSArray is copying itself by instantiating a ContiguousArray from _ArrayBuffer:

struct _ArrayBuffer {
  internal func withUnsafeBufferPointer<R>(
    if _fastPath(_isNative) {...    }
    return try ContiguousArray(self).withUnsafeBufferPointer(body)
  }
}

If I understand it, that performance bug would not be caught without the current assert.

Maybe the right thing to do is just ignore layering and fully implement _[*]ArrayBuffer._copyContents. It looks like the version taking a subRange already exists and now there's a test case for the one that takes a buffer.

I might still suggest that the right long-term fix is to move to eager bridging.

[lorentey]

Filed https://bugs.swift.org/browse/SR-14663 for the stdlib issue.

We'll continue to use this issue to track the package-level workaround, which I'll submit soon.

[lorentey]

Note: this also affects Deque.prepend and Deque.append, as they're also calling wCSIA on a user-supplied collection. 😩