digitalmars.D - Severe 2.084 regression when using staticArray on array of struct with
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (33/33) Feb 12 2019 The following code
- Nicholas Wilson (32/37) Feb 12 2019 This appears to be a DMD only issue that has never worked (works
- ag0aep6g (20/48) Feb 12 2019 Ouch. That looks bad. A reduction:
- jmh530 (20/40) Feb 12 2019 For whatever strange reason, your post gave me a completely
- John Colvin (6/44) Feb 12 2019 There are plenty of tests of things that fail already in the dmd
- Jacob Carlborg (7/28) Feb 12 2019 Should be pretty straightforward to add to the new test runner [1]. It
- Seb (6/27) Feb 12 2019 This has already existed for several years now:
- jmh530 (3/9) Feb 12 2019 Cool. I did not know that. It's always good when you think you
- Basile B. (70/118) Feb 12 2019 It's a bad codegen, or what i would call trivially "an ABI
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/11) Feb 12 2019 So I take it you file Bugzilla issue, then? ;)
- Basile B. (4/7) Feb 12 2019 Yes i can try to open something. Also since now it's almost sure
- Basile B. (2/13) Feb 12 2019 https://issues.dlang.org/show_bug.cgi?id=19672
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Feb 12 2019 Thanks!
- Basile B. (2/4) Feb 12 2019 correction: I meant 17, not 33.
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (6/10) Feb 13 2019 Does this happen for every struct `S`, where
- Simen =?UTF-8?B?S2rDpnLDpXM=?= (7/18) Feb 13 2019 S.sizeof 9 to 16, only for long and ulong. Order doesn't matter.
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/7) Feb 13 2019 Thanks. Can you add that to the issue?
- ag0aep6g (4/5) Feb 12 2019 This one looks like it might be related, but it doesn't seem to be a
- Walter Bright (2/6) Feb 12 2019 Related issues can be added to the "See Also" thing on the Bugzilla page...
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (4/11) Feb 13 2019 Thanks you, Walter.
- Temtaime (4/16) Feb 14 2019 Lol, how many other bugs we will face before one will comprehend
- Basile B. (5/24) Feb 14 2019 I don't know how many but this morning i've seen another nice one
- ag0aep6g (4/9) Feb 14 2019 Change the type to `real` and it fails on x64, too. Issue was a
- H. S. Teoh (6/16) Feb 14 2019 Maybe if we make enough noise about it, it would get fixed in the near
- ag0aep6g (4/6) Feb 14 2019 Maybe. But is that how bugs should be prioritized? Be the most annoying
- H. S. Teoh (7/14) Feb 14 2019 No. I think the problem here is that there are far too many bugs to
- Patrick Schluter (2/15) Feb 15 2019 Proven right. The bug has been fixed rapidly.
- Basile B. (6/23) Feb 14 2019 Maybe a bit of RE at the machine code level can help to target
- Joseph Rushton Wakeling (6/18) Feb 15 2019 Is this going to make it into a v2.084 point release (presumably
- Seb (7/28) Feb 15 2019 As explained on Slack, there very likely will be no v2.084.2 as
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 2019
Nicholas Wilson <iamthewilsonator hotmail.com> 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 2019
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 2019
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 2019
On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote:On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote: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".[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/LBhn4lFor 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.
Feb 12 2019
On 2019-02-12 19:33, John Colvin wrote:On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote: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 CarlborgFor 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 2019
On Tuesday, 12 February 2019 at 18:26:56 UTC, jmh530 wrote:On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote: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).[...]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 2019
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 2019
On Tuesday, 12 February 2019 at 14:44:10 UTC, ag0aep6g wrote:On 12.02.19 15:06, Per Nordlöw wrote: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 ;-------------------------------------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 2019
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 2019
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: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.;------- SUB 000000000045119Ch -------; showDmdBadCodegenSo I take it you file Bugzilla issue, then? ;)
Feb 12 2019
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:https://issues.dlang.org/show_bug.cgi?id=19672;------- 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 2019
On Tuesday, 12 February 2019 at 21:11:47 UTC, Basile B. wrote:Thanks!So I take it you file Bugzilla issue, then? ;)https://issues.dlang.org/show_bug.cgi?id=19672
Feb 12 2019
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 2019
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:Does this happen for every struct `S`, where S.sizeof <= 16 or does S.tupleof play a role aswell?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 13 2019
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: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. -- SimenOn Tuesday, 12 February 2019 at 20:26:55 UTC, Basile B. wrote:Does this happen for every struct `S`, where S.sizeof <= 16 or does S.tupleof play a role aswell?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 13 2019
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 2019
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 2019
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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 12 2019
On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright wrote:On 2/12/2019 7:01 AM, ag0aep6g wrote:Thanks you, Walter. https://github.com/dlang/dmd/pull/9357This 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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 13 2019
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:Lol, how many other bugs we will face before one will comprehend that dmd's codegen is not suitable for an «official» compiler implementation.On 2/12/2019 7:01 AM, ag0aep6g wrote:Thanks you, Walter. https://github.com/dlang/dmd/pull/9357This 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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 14 2019
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: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.On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright wrote:Lol, how many other bugs we will face before one will comprehend that dmd's codegen is not suitable for an «official» compiler implementation.On 2/12/2019 7:01 AM, ag0aep6g wrote:Thanks you, Walter. https://github.com/dlang/dmd/pull/9357This 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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 14 2019
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 2019
On Thu, Feb 14, 2019 at 09:59:27PM +0100, ag0aep6g via Digitalmars-d wrote:On 14.02.19 21:36, Basile B. wrote: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.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 2019
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 2019
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: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.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 2019
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:Proven right. The bug has been fixed rapidly.On 14.02.19 22:28, H. S. Teoh wrote: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.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 15 2019
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: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.On 14.02.19 21:36, Basile B. wrote:Maybe if we make enough noise about it, it would get fixed in the near future? TI 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 2019
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: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.On 2/12/2019 7:01 AM, ag0aep6g wrote:Thanks you, Walter. https://github.com/dlang/dmd/pull/9357This 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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 15 2019
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: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.On Wednesday, 13 February 2019 at 07:34:05 UTC, Walter Bright wrote: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.On 2/12/2019 7:01 AM, ag0aep6g wrote:Thanks you, Walter. https://github.com/dlang/dmd/pull/9357This 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=15075Related issues can be added to the "See Also" thing on the Bugzilla page.
Feb 15 2019