chore: add array and slice control flow tests

[michaeljklein]

Description

TODO

• Make note to finish slice test after pop_front issue: [T]::pop_front() panics when inside non-executed if #5462
• Refactor any::<T>()
• Make issues for failing tests

Problem*

Part of #5362

Summary*

Simple combinator-based parsing tests for control flow.

• Originally designed for slices, but adapted to arrays by emulating slices as bounded vectors

struct Bvec<T, let N: u32> {
    inner: [T; N],

    // elements at indices < offset are zero
    offset: u32, 

    // elements at indices >= len are zero
    len: u32,
}

Additional Context

This code is hacky, but let me know if any parts are worth cleaning up for the stdlib, e.g. reverse_array.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[jfecher]

These tests look quite large - what features do they test?

[michaeljklein]

@jfecher I don't have a list of specific features, because this test was designed for general non-trivial control flow with collections.

I had noticed that most of the control flow in our tests was fairly simple:

• Many tests simply call stdlib functions, but with too few inputs to expect full coverage of those functions.
• Of the more complex tests:
  • Some are designed by the feature implementer to exercise the feature, with varying coverage of that feature.
  • Most of the rest are minimizations of user-found errors.

And so I wrote this expecting that we had bugs in code with slightly-less-trivial control flow.

Investigating implementing this, I found:

• Calling lambda from array or slice panics #5503

And then I found the following issues directly from implementing these tests:

• [T]::pop_front() panics when inside non-executed if #5462
• Turbofish for numeric generics in nested function call fails #5442
• Numeric generic struct parameter panics when accessed uninitialized #5436
• Option<[u8]>::none() panics at SSA #5429

[jfecher]

Reasoning sounds good. I do like to avoid larger tests when possible since when they do fail it is more difficult to isolate exactly why. Especially if it is a runtime/SSA issue rather than a type one. One large test here and there isn't that bad though.

I'm also unsure why we need an array version and a slice version of the same test. It seems like the slice version has more bugs so maybe we should keep that one? The library itself is pretty cool though and may be something that we want to expose in its own repo.

[michaeljklein]

I'm also unsure why we need an array version and a slice version of the same test. It seems like the slice version has more bugs so maybe we should keep that one? The library itself is pretty cool though and may be something that we want to expose in its own repo.

• I had hoped that the array version would find more bugs. Since it's more complete, I'll move it to a comment in the slice test for when those issues are fixed.
• R.e. having in its own repo: perhaps, but it currently lacks many convenience functions and I'm not sure what it'd need to be production ready.