www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Severe 2.084 regression when using staticArray on array of struct with

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
The following code

class C
{
     this(int i) { this.i = i; }
     int i;
}

struct S
{
     C c;
     bool b;                  // removing this prevents bug
}

void main()
{
     import std.stdio : writeln;
     import std.array : staticArray;

     auto c = new C(42);

     const S[1] s1 = [S(c)].staticArray;
     const S[1] s2 = [S(c)];

     writeln(cast(void*)s1[0].c);
     writeln(cast(void*)s2[0].c);

     assert(s1[0].c is
            s2[0].c);
}

outputs

20
7F6CDAAC0000
core.exception.AssertError static_array_of_struct_of_class_and_boole
n_regression.d(26): Assertion failure

on my Ubuntu 18.04 x86_64 machine.

When I remove the member `b` in `S` the faulty behavior goes 
away. A regression I presume.

Has anybody already filed this in Bugzilla?

The regression happens on dmd 2.084.1 and master but not in 
latest ldc beta.
Feb 12
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Tuesday, 12 February 2019 at 14:06:44 UTC, Per Nordlöw wrote:
 When I remove the member `b` in `S` the faulty behavior goes 
 away. A regression I presume.

 Has anybody already filed this in Bugzilla?

 The regression happens on dmd 2.084.1 and master but not in 
 latest ldc beta.
This appears to be a DMD only issue that has never worked (works in both ldc and ldc-beta): 2.079.1 to 2.081.2: Failure with output: onlineapp.d(16): Error: module `std.array` import `staticArray` not found 2.082.1: Failure with output: ----- core.exception.AssertError onlineapp.d(26): Assertion failure ---------------- ??:? _d_assertp [0x44b585] onlineapp.d:26 _Dmain [0x43da4d] 7FFF6ABE6570 7F9104966000 ----- 2.083.1: Failure with output: ----- core.exception.AssertError onlineapp.d(26): Assertion failure ---------------- ??:? _d_assertp [0x44f21d] onlineapp.d:26 _Dmain [0x4404cd] null 7FB5316C5000 ----- Since 2.084.0: Failure with output: ----- core.exception.AssertError onlineapp.d(26): Assertion failure ---------------- ??:? _d_assertp [0x44f484] onlineapp.d:26 _Dmain [0x4409fd] 7FFDEE9C7A70 7EFD5A03B000 -----
Feb 12
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 12.02.19 15:06, Per Nordlöw wrote:
 class C
 {
      this(int i) { this.i = i; }
      int i;
 }
 
 struct S
 {
      C c;
      bool b;                  // removing this prevents bug
 }
 
 void main()
 {
      import std.stdio : writeln;
      import std.array : staticArray;
 
      auto c = new C(42);
 
      const S[1] s1 = [S(c)].staticArray;
      const S[1] s2 = [S(c)];
 
      writeln(cast(void*)s1[0].c);
      writeln(cast(void*)s2[0].c);
 
      assert(s1[0].c is
             s2[0].c);
 }
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
Feb 12
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Feb 12
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote:
 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.
There are plenty of tests of things that fail already in the dmd test suite, the only difference being that those are for things that *should* fail. I put this sort of idea to Walter 1 or 2 DConfs ago, I think the result was "That sounds interesting, someone should do it".
Feb 12
parent Jacob Carlborg <doob me.com> writes:
On 2019-02-12 19:33, John Colvin wrote:
 On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote:
 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.
There are plenty of tests of things that fail already in the dmd test suite, the only difference being that those are for things that *should* fail. I put this sort of idea to Walter 1 or 2 DConfs ago, I think the result was "That sounds interesting, someone should do it".
Should be pretty straightforward to add to the new test runner [1]. It already looks for UDAs on unittest blocks. The tests look like this [2]. [1] https://github.com/dlang/dmd/blob/master/test/tools/unit_test_runner.d [2] https://github.com/dlang/dmd/blob/master/test/unit/self_test.d -- /Jacob Carlborg
Feb 12
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote:
 On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote:
 [...]
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.
This has already existed for several years now: https://github.com/CyberShadow/DBugTests However, as currently bugs are reported in a non-structured way I think the curation is only partially automated and thus a lot of work (which needs to be done by someone).
Feb 12
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 February 2019 at 19:31:56 UTC, Seb wrote:
 [snip]

 This has already existed for several years now:

 https://github.com/CyberShadow/DBugTests

 However, as currently bugs are reported in a non-structured way 
 I think the curation is only partially automated and thus a lot 
 of work (which needs to be done by someone).
Cool. I did not know that. It's always good when you think you have an interesting idea and somebody thought to do it years ago!
Feb 12
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote:
 On 12.02.19 15:06, Per Nordlöw wrote:
 class C
 {
      this(int i) { this.i = i; }
      int i;
 }
 
 struct S
 {
      C c;
      bool b;                  // removing this prevents bug
 }
 
 void main()
 {
      import std.stdio : writeln;
      import std.array : staticArray;
 
      auto c = new C(42);
 
      const S[1] s1 = [S(c)].staticArray;
      const S[1] s2 = [S(c)];
 
      writeln(cast(void*)s1[0].c);
      writeln(cast(void*)s2[0].c);
 
      assert(s1[0].c is
             s2[0].c);
 }
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
It's a bad codegen, or what i would call trivially "an ABI disagreement", explaining why LDC doesn't exhibits the bug. As far as I can see the problem is that the static array is passed by the registers, so under linux, `c` in RDI, and `b` in RSI but then in `f()` the backend thinks that it's passed using the stack. The bug goes away when S size is over or equal to 33 bytes because in this case the parameter is well copied. material leading to this conclusion: ``` struct S { ulong c; bool b; // removing this prevents bug } import disassembler, std.stdio; // godbolt is too noisy with dmd so i use mine void main() { S[1] a = [S(42, true)]; showThatRegsAreUsed(a); showDmdBadCodegen(a); writeln(prettyDisasm(&showThatRegsAreUsed)); writeln(prettyDisasm(&showDmdBadCodegen)); } void showDmdBadCodegen(S[1] a) { writeln(a[0].c); } void showThatRegsAreUsed(S[1] a) { alias writeul = writeln!ulong; asm { naked; push RSI; call writeul; // 1st param, so 42 pop RSI; mov RDI, RSI; call writeul; // 2nd so RSI ret; } } ``` output: compiling /tmp/temp_7F711D03FA50.d using /usr/bin/dmd (dmd) /tmp/temp_7F711D03FA50.d successfully compiled Runnable build duration: 0 minutes, 0 seconds and 399 msecs 42 1 0 ;------- SUB 00000000004511ACh -------; showThatRegsAreUsed 00000000004511ACh push rsi 00000000004511ADh call 00000000004516FCh 00000000004511B2h pop rsi 00000000004511B3h mov rdi, rsi 00000000004511B6h call 00000000004516FCh 00000000004511BBh ret ;------------------------------------- ;------- SUB 000000000045119Ch -------; showDmdBadCodegen 000000000045119Ch push rbp 000000000045119Dh mov rbp, rsp 00000000004511A0h mov rdi, qword ptr [rbp+10h] ; ouch 42 is erased here ! 00000000004511A4h call 00000000004516FCh 00000000004511A9h pop rbp 00000000004511AAh ret ;-------------------------------------
Feb 12
next sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 ;------- SUB 000000000045119Ch -------; showDmdBadCodegen
 000000000045119Ch  push rbp
 000000000045119Dh  mov rbp, rsp
 00000000004511A0h  mov rdi, qword ptr [rbp+10h] ; ouch 42 is 
 erased here !
 00000000004511A4h  call 00000000004516FCh
 00000000004511A9h  pop rbp
 00000000004511AAh  ret
 ;-------------------------------------
So I take it you file Bugzilla issue, then? ;)
Feb 12
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 12 February 2019 at 20:48:04 UTC, Per Nordlöw wrote:
 On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 ;------- SUB 000000000045119Ch -------; showDmdBadCodegen
So I take it you file Bugzilla issue, then? ;)
Yes i can try to open something. Also since now it's almost sure that it's not the same as 15075 since t doesn't imply parameter passing.
Feb 12
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 12 February 2019 at 20:48:04 UTC, Per Nordlöw wrote:
 On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 ;------- SUB 000000000045119Ch -------; showDmdBadCodegen
 000000000045119Ch  push rbp
 000000000045119Dh  mov rbp, rsp
 00000000004511A0h  mov rdi, qword ptr [rbp+10h] ; ouch 42 is 
 erased here !
 00000000004511A4h  call 00000000004516FCh
 00000000004511A9h  pop rbp
 00000000004511AAh  ret
 ;-------------------------------------
So I take it you file Bugzilla issue, then? ;)
https://issues.dlang.org/show_bug.cgi?id=19672
Feb 12
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 12 February 2019 at 21:11:47 UTC, Basile B. wrote:
 So I take it you file Bugzilla issue, then? ;)
https://issues.dlang.org/show_bug.cgi?id=19672
Thanks!
Feb 12
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 The bug goes away when S size is over or equal to 33 bytes 
 because in this case the parameter is well copied.
correction: I meant 17, not 33.
Feb 12
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 12 February 2019 at 21:01:12 UTC, Basile B. wrote:
 On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 The bug goes away when S size is over or equal to 33 bytes 
 because in this case the parameter is well copied.
correction: I meant 17, not 33.
Does this happen for every struct `S`, where S.sizeof <= 16 or does S.tupleof play a role aswell?
Feb 13
parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 13 February 2019 at 09:05:17 UTC, Per Nordlöw wrote:
 On Tuesday, 12 February 2019 at 21:01:12 UTC, Basile B. wrote:
 On Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:
 The bug goes away when S size is over or equal to 33 bytes 
 because in this case the parameter is well copied.
correction: I meant 17, not 33.
Does this happen for every struct `S`, where S.sizeof <= 16 or does S.tupleof play a role aswell?
S.sizeof 9 to 16, only for long and ulong. Order doesn't matter. Tested with other 8-byte types like double, int[2], short[4], ubyte[8], and it works fine. The type of the padding field also doesn't seem to matter. -- Simen
Feb 13
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 13 February 2019 at 10:10:21 UTC, Simen Kjærås 
wrote:
 S.sizeof 9 to 16, only for long and ulong. Order doesn't 
 matter. Tested with other 8-byte types like double, int[2], 
 short[4], ubyte[8], and it works fine. The type of the padding 
 field also doesn't seem to matter.
Thanks. Can you add that to the issue?
Feb 13
prev sibling parent reply ag0aep6g <anonymous example.com> writes:
On 12.02.19 15:06, Per Nordlöw wrote:
 Has anybody already filed this in Bugzilla?
This one looks like it might be related, but it doesn't seem to be a true duplicate: https://issues.dlang.org/show_bug.cgi?id=15075
Feb 12
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem to be a true 
 duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 12
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright 
wrote:
 On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem 
 to be a true duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Thanks you, Walter. https://github.com/dlang/dmd/pull/9357
Feb 13
next sibling parent reply Temtaime <temtaime gmail.com> writes:
On Wednesday, 13 February 2019 at 11:21:31 UTC, Per Nordlöw wrote:
 On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright 
 wrote:
 On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem 
 to be a true duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Thanks you, Walter. https://github.com/dlang/dmd/pull/9357
Lol, how many other bugs we will face before one will comprehend that dmd's codegen is not suitable for an «official» compiler implementation.
Feb 14
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 14 February 2019 at 18:11:28 UTC, Temtaime wrote:
 On Wednesday, 13 February 2019 at 11:21:31 UTC, Per Nordlöw 
 wrote:
 On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright 
 wrote:
 On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem 
 to be a true duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Thanks you, Walter. https://github.com/dlang/dmd/pull/9357
Lol, how many other bugs we will face before one will comprehend that dmd's codegen is not suitable for an «official» compiler implementation.
I don't know how many but this morning i've seen another nice one in bugzilla : https://issues.dlang.org/show_bug.cgi?id=19437 Hopefully nobody makes 32-bit apps anymore.
Feb 14
parent reply ag0aep6g <anonymous example.com> writes:
On 14.02.19 21:36, Basile B. wrote:
 I don't know how many but this morning i've seen another nice one in 
 bugzilla :
 https://issues.dlang.org/show_bug.cgi?id=19437
 
 Hopefully nobody makes 32-bit apps anymore.
Change the type to `real` and it fails on x64, too. Issue was a duplicate of <https://issues.dlang.org/show_bug.cgi?id=18573>. Known for about a year.
Feb 14
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 14, 2019 at 09:59:27PM +0100, ag0aep6g via Digitalmars-d wrote:
 On 14.02.19 21:36, Basile B. wrote:
 I don't know how many but this morning i've seen another nice one in
 bugzilla :
 https://issues.dlang.org/show_bug.cgi?id=19437
 
 Hopefully nobody makes 32-bit apps anymore.
Change the type to `real` and it fails on x64, too. Issue was a duplicate of <https://issues.dlang.org/show_bug.cgi?id=18573>. Known for about a year.
Maybe if we make enough noise about it, it would get fixed in the near future? T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Feb 14
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 14.02.19 22:28, H. S. Teoh wrote:
 Maybe if we make enough noise about it, it would get fixed in the near
 future?
Maybe. But is that how bugs should be prioritized? Be the most annoying and your thing gets fixed first (or at all)? That's not a game I want to play.
Feb 14
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 14, 2019 at 11:10:06PM +0100, ag0aep6g via Digitalmars-d wrote:
 On 14.02.19 22:28, H. S. Teoh wrote:
 Maybe if we make enough noise about it, it would get fixed in the
 near future?
Maybe. But is that how bugs should be prioritized? Be the most annoying and your thing gets fixed first (or at all)? That's not a game I want to play.
No. I think the problem here is that there are far too many bugs to work on and far too few people working on them, that if you want timely results, you pretty much have to bring it to people's attention. T -- MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.
Feb 14
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 14 February 2019 at 22:25:19 UTC, H. S. Teoh wrote:
 On Thu, Feb 14, 2019 at 11:10:06PM +0100, ag0aep6g via 
 Digitalmars-d wrote:
 On 14.02.19 22:28, H. S. Teoh wrote:
 Maybe if we make enough noise about it, it would get fixed 
 in the near future?
Maybe. But is that how bugs should be prioritized? Be the most annoying and your thing gets fixed first (or at all)? That's not a game I want to play.
No. I think the problem here is that there are far too many bugs to work on and far too few people working on them, that if you want timely results, you pretty much have to bring it to people's attention.
Proven right. The bug has been fixed rapidly.
Feb 15
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 14 February 2019 at 21:28:13 UTC, H. S. Teoh wrote:
 On Thu, Feb 14, 2019 at 09:59:27PM +0100, ag0aep6g via 
 Digitalmars-d wrote:
 On 14.02.19 21:36, Basile B. wrote:
 I don't know how many but this morning i've seen another 
 nice one in
 bugzilla :
 https://issues.dlang.org/show_bug.cgi?id=19437
 
 Hopefully nobody makes 32-bit apps anymore.
Change the type to `real` and it fails on x64, too. Issue was a duplicate of <https://issues.dlang.org/show_bug.cgi?id=18573>. Known for about a year.
Maybe if we make enough noise about it, it would get fixed in the near future? T
Maybe a bit of RE at the machine code level can help to target the issue and to refine the bug report. I believe that the issue of the OP was quickly fixed because of that kind of work. It was really easier to look at the disasm rather than trying to understand the backend end and put some printf everywhere.
Feb 14
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 13 February 2019 at 11:21:31 UTC, Per Nordlöw wrote:
 On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright 
 wrote:
 On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem 
 to be a true duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Thanks you, Walter. https://github.com/dlang/dmd/pull/9357
Is this going to make it into a v2.084 point release (presumably v2.084.2)? If so, is there an ETA for this release? Asking because I want to confirm if, given this regression, it's better to use v2.084.1 in the snap package, or to release v2.084.0 and wait for the .2 point release.
Feb 15
parent Seb <seb wilzba.ch> writes:
On Friday, 15 February 2019 at 11:09:28 UTC, Joseph Rushton 
Wakeling wrote:
 On Wednesday, 13 February 2019 at 11:21:31 UTC, Per Nordlöw 
 wrote:
 On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright 
 wrote:
 On 2/12/2019 7:01 AM, ag0aep6g wrote:
 This one looks like it might be related, but it doesn't seem 
 to be a true duplicate:
 
 https://issues.dlang.org/show_bug.cgi?id=15075
Related issues can be added to the "See Also" thing on the Bugzilla page.
Thanks you, Walter. https://github.com/dlang/dmd/pull/9357
Is this going to make it into a v2.084 point release (presumably v2.084.2)? If so, is there an ETA for this release? Asking because I want to confirm if, given this regression, it's better to use v2.084.1 in the snap package, or to release v2.084.0 and wait for the .2 point release.
As explained on Slack, there very likely will be no v2.084.2 as the master/stable branch-off for 2.085.0 should happen this weekend and there's only limited manpower for releases (aka Martin). Thus, is best to use v2.084.1 for now.
Feb 15