Severe 2.084 regression when using staticArray on array of struct with class and bool member

[jmh530]

On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote:
> [snip]
>
> Ouch. That looks bad. A reduction:
>
> ----
> struct S
> {
>     ulong c;
>     bool b;                  // removing this prevents bug
> }
>
> void main()
> {
>     S[1] a = [S(42)];
>     assert(a[0].c == 42); /* Passes. */
>     f(a);
> }
>
> void f(S[1] a)
> {
>     assert(a[0].c == 42); /* Fails. */
> }
> ----
>
> Fails since 2.070. https://run.dlang.io/is/LBhn4l

For whatever strange reason, your post gave me a completely 
unrelated idea:

When we have issues like this that get posted to bugzilla, there 
is (almost) always a code snippet, but unittests are only created 
when there an actual fix has been made. Except for what is in 
bugzilla DMD's source doesn't really know anything about the 
interaction of bugs. For instance, if fixing one bug would also 
fix another, we wouldn't know that unless someone marked a bug as 
duplicate.

To improve the situation, we could add a unittest for every new 
bug. The immediate problem with this is that since these are 
bugs, they would all fail. The first way to fix this is that all 
the bug unittest would be in a version block, so they would only 
get tested on purpose. The second way is that something like 
unit-threaded's @ShouldFail could be added to the language and 
applied to all these bugs. Then, the unittest will only have an 
error when the bug is fixed and the @ShouldFail can be removed. 
It will then be easier to identify when a bug fix resolves 
multiple, potentially related issues.