cc @slavapestov, @mikeash, @eeckstein

IUO does not have a runtime representation so it should be possible to reproduce the issue with a plain Optional.

@slavapestov As I said in the description, this issue wasn't reproducible outside of Swift Benchmarking Suite, even when I have copied the code unchanged. It's a stretch to say it should be reproducible with Optional… Can somebody have a look at this? (I'm hesitant to finish the PR with unresolved issues around benchmark setup overhead this bug is causing.)

This bug is still reproducible by uncommenting the alternative grabArray in the PR #20666 which has been rebased on latest master.

PR #20666 has been merged (the benchmarks were refactored, but remain skipped from the pre-commit performance testing), so it should now be possible for everybody to reproduce this bug on master by uncommenting the alternative versions of grabArray.

cc aschwaighofer@apple.com (JIRA User), @eeckstein

Ehm. I apologize, am an idiot… there is no bug here. This is crashing on a second sample, when the grabbed array is indeed set to nil, ergo the crash when dereferencing the Optional.

The proper way to get rid of the setup overhead in those benchmarks is to copy the fresh array on each iteration, which also fixes the different amount of work these tests were doing between first and subsequent iterations.