@swift-ci create

apple/swift-nio#1893

Thanks for fixing NIO. If this is going to need to be updated in other projects too, particularly since it was just added to Swift 5.5, maybe this breaking change and how to fix it should be publicly documented somewhere, though I'm unsure where that would be.

I will see whether I can get an item added to release notes.
Note that I am interested in knowing whether what happened to NIO happens anywhere else.

The standard library bug that we fixed allowed incomplete Collection conformances to compile. NIO was the only project to hit this from the compatibility suite. There are 4 essential conditions for a project to stop compiling due to this:

1. It needs to implement a new Collection,
2. That Collection defines a non-default SubSequence (that is, it declares that it doesn't want to use Slice),
3. That Collection does not define the slicing subscript (subscript(bounds: Range<Index>)),
4. The slicing subscript is not used or tested.

The first 3 meant that another utility subscript<R: RangeExpression>(_ range: R) was inadvertently getting picked up to satisfy the requirement, and with those conditions combined it ended up calling itself, resulting in a stack overflow if called at runtime.

Item 4 is key: any use of that slicing subscript would have resulted in a crash. PR-38161 converted the latent bug to a compilation error.

Alright, seems like a worthwhile change and if you think it's a rare issue, should be no problem.

theindigamer (JIRA User), please close if you're happy, I'm good.

NIO has enacted an even better fix: removing the NIO1 API shims where this problem occurred. apple/swift-nio#1897