www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage

reply "Daniel Kozak" <kozzi11 gmail.com> writes:
This code compile fine under both versions:

dmd (2.066, -debug -d):
OK

dmd (2.067, -debug -d):
core.exception.AssertError main.d(24): Assertion failure
----------------
./main() [0x46413f]
./main(_Dmain+0x86) [0x449996]
./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) 
[0x467d53]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())+0x2a) 
[0x467ca6]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll()+0x30) [0x467d0c]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())+0x2a) 
[0x467ca6]
./main(_d_run_main+0x1dc) [0x467c20]
./main(main+0x17) [0x464157]
/usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]
Apr 22 2015
next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
static struct S
{
      immutable FLAG_ON = 1;
      immutable FLAG_GPRS = 2;
      immutable FLAG_HIDDEN = 4;
      ubyte flags;
      ubyte value;

      bool isFlagSet(int flag)
      {
          return flags && flag == flag;
      }
}

void main(string[ ] args)
{
      auto someData = [0x01, 0x10, 0x02, 0x16, 0x04, 0x08];
      auto countS = someData.length / S.sizeof;

      S[] sArray = (cast(S*)someData.ptr)[0 .. countS];
      assert(sArray.length == 3);
}
Apr 22 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 22 April 2015 at 11:29:30 UTC, Daniel Kozak wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
 static struct S
 {
      immutable FLAG_ON = 1;
      immutable FLAG_GPRS = 2;
      immutable FLAG_HIDDEN = 4;
      ubyte flags;
      ubyte value;

      bool isFlagSet(int flag)
      {
          return flags && flag == flag;
      }
 }

 void main(string[ ] args)
 {
      auto someData = [0x01, 0x10, 0x02, 0x16, 0x04, 0x08];
      auto countS = someData.length / S.sizeof;

      S[] sArray = (cast(S*)someData.ptr)[0 .. countS];
      assert(sArray.length == 3);
 }


I agree that the change should be more prominent in the changelog.

Having said that, if your code makes an assumption about the 
layout (alignment and size) of a struct, it should `static 
assert` that assumption, or at least have a test case that relies 
it. You're just asking for trouble without that.
Apr 22 2015
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):
 OK

 dmd (2.067, -debug -d):
 core.exception.AssertError main.d(24): Assertion failure
 ----------------
 ./main() [0x46413f]
 ./main(_Dmain+0x86) [0x449996]
 ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) 
 [0x467d53]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
 function(char[][])*).tryExec(scope void delegate())+0x2a) 
 [0x467ca6]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
 function(char[][])*).runAll()+0x30) [0x467d0c]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int 
 function(char[][])*).tryExec(scope void delegate())+0x2a) 
 [0x467ca6]
 ./main(_d_run_main+0x1dc) [0x467c20]
 ./main(main+0x17) [0x464157]
 /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]


What code?
Apr 22 2015
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
The worst thing is a runtime breakage and there is almost zero 
information in changelog for 2.067
Apr 22 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


-d is your enemy, If you remove that, there will be a clear 
warning "Deprecation: variable XXX.S.FLAG_ON immutable field with 
initializer should be static, __gshared, or an enum". You decided 
to ignore and hide it, why the surprise about the breakage?
Apr 22 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


 -d is your enemy, If you remove that, there will be a clear 
 warning "Deprecation: variable XXX.S.FLAG_ON immutable field 
 with initializer should be static, __gshared, or an enum". You 
 decided to ignore and hide it, why the surprise about the 
 breakage?


The changelog entry comes from 2.065 : 
http://dlang.org/changelog.html#staticfields2

It would be probably good to repeat it in 2.067 now that new 
semantics have effect but the fault of ignoring deprecation 
messages before migration is 100% on user.
Apr 22 2015
prev sibling next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


 -d is your enemy, If you remove that, there will be a clear 
 warning "Deprecation: variable XXX.S.FLAG_ON immutable field 
 with initializer should be static, __gshared, or an enum". You 
 decided to ignore and hide it, why the surprise about the 
 breakage?


I decided to ignore deprication messages, but I never expect it 
could lead to change semantics. I would expect compile breakage 
on 2.067 and after some releases maybe change of semantics. Btw. 
on 2.067 its compile even without -d parameter
Apr 22 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 22 April 2015 at 11:41:53 UTC, Daniel Kozak wrote:

 On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak 
 wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


 -d is your enemy, If you remove that, there will be a clear 
 warning "Deprecation: variable XXX.S.FLAG_ON immutable field 
 with initializer should be static, __gshared, or an enum". You 
 decided to ignore and hide it, why the surprise about the 
 breakage?


 I decided to ignore deprication messages, but I never expect it 
 could lead to change semantics. I would expect compile breakage 
 on 2.067 and after some releases maybe change of semantics. 
 Btw. on 2.067 its compile even without -d parameter


It should have been an error in 2.066 according to plan published 
in 2.065
If it didn't happen, shifting the schedule for one release may be 
justified.
Apr 22 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/22/15 7:41 AM, Daniel Kozak wrote:

 On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


 -d is your enemy, If you remove that, there will be a clear warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
 should be static, __gshared, or an enum". You decided to ignore and
 hide it, why the surprise about the breakage?


 I decided to ignore deprication messages, but I never expect it could
 lead to change semantics. I would expect compile breakage on 2.067 and
 after some releases maybe change of semantics. Btw. on 2.067 its compile
 even without -d parameter


You are misunderstanding what deprecation means then. The whole point is 
"the semantics are going to change, please update your code, it's coming 
soon". The -d is a way to get your code to compile now while you update.

-Steve
Apr 22 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 22 April 2015 at 16:10:37 UTC, Steven Schveighoffer 
wrote:

 You are misunderstanding what deprecation means then. The whole 
 point is "the semantics are going to change, please update your 
 code, it's coming soon". The -d is a way to get your code to 
 compile now while you update.


So semantics can change just fine, a period of turning 
deprecation into an error is not needed at all?
Apr 23 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/23/15 6:14 AM, Kagamin wrote:

 On Wednesday, 22 April 2015 at 16:10:37 UTC, Steven Schveighoffer wrote:

 You are misunderstanding what deprecation means then. The whole point
 is "the semantics are going to change, please update your code, it's
 coming soon". The -d is a way to get your code to compile now while
 you update.


 So semantics can change just fine, a period of turning deprecation into
 an error is not needed at all?


Possibly this could have happened. Kind of too late now, though.

But the reason it probably did not happen, is that for code that makes 
no assumptions about whether immutable fields affect struct layout or 
not, there is no danger. Only if you do dangerous stuff like casting raw 
bytes to a struct with immutable fields will you have problems. The OP 
code is dangerous with or without this change.

As a general teaching moment, however, please don't ignore deprecation 
messages. They aren't just for laughs.

And all is not lost! Just compile with 2.066 without -d switch and fix 
all your errors with initialized immutables.

-Steve
Apr 23 2015
parent reply "Dicebot" <public dicebot.lv> writes:
We can make it an error in 2.067.1 and change semantics in 2.067 
- actually I'd recommend to do it that way. Breaking normal 
deprecation process is not good.
Apr 23 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/23/15 9:09 AM, Dicebot wrote:

 We can make it an error in 2.067.1 and change semantics in 2.067 -
 actually I'd recommend to do it that way. Breaking normal deprecation
 process is not good.


I agree it should have been done, not saying it's OK to break the 
process in some cases. I'm just explaining why it probably happened the 
way it did.

However, breaking it again in 2.067.1 is not good. Anyone who creates 
immutable fields for 2.067 and then upgrades to 2.067.1 is going to be 
upset. Even if we agree on how semantic changes should happen in the 
future (and should have happened in the past), it's not acceptable to 
change them for a point release.

-Steve
Apr 23 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:

 On 4/23/15 9:09 AM, Dicebot wrote:

 We can make it an error in 2.067.1 and change semantics in 2.067 -
 actually I'd recommend to do it that way. Breaking normal deprecation
 process is not good.


 I agree it should have been done, not saying it's OK to break the process in
 some cases. I'm just explaining why it probably happened the way it did.


Yes, it should have been done. We screwed up.


 However, breaking it again in 2.067.1 is not good. Anyone who creates immutable
 fields for 2.067 and then upgrades to 2.067.1 is going to be upset. Even if we
 agree on how semantic changes should happen in the future (and should have
 happened in the past), it's not acceptable to change them for a point release.


Unfortunately, you're right.
Apr 23 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote:

 On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:

 I agree it should have been done, not saying it's OK to break 
 the process in
 some cases. I'm just explaining why it probably happened the 
 way it did.


 Yes, it should have been done. We screwed up.


It's time that we agree on/document an official deprecation 
approach and rigorously enforce it, making as few exceptions as 
possible. As it stands now, everyone follows their own policy. 
Any volunteer to put this in a DIP?
Apr 24 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 24 April 2015 at 09:22, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote:

 On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:

 I agree it should have been done, not saying it's OK to break the process
 in
 some cases. I'm just explaining why it probably happened the way it did.



 Yes, it should have been done. We screwed up.



 It's time that we agree on/document an official deprecation approach and
 rigorously enforce it, making as few exceptions as possible. As it stands
 now, everyone follows their own policy. Any volunteer to put this in a DIP?


One thing I noticed is that for many deprecations / planned
deprecations, there is no issue in bugzilla  (Override? .sort?)

I hope you don't mind me doing the honours.

https://issues.dlang.org/show_bug.cgi?id=14488
https://issues.dlang.org/show_bug.cgi?id=14489
https://issues.dlang.org/show_bug.cgi?id=14490
https://issues.dlang.org/show_bug.cgi?id=14491
https://issues.dlang.org/show_bug.cgi?id=14492

Regards
Iain
Apr 24 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/24/2015 12:22 AM, Martin Nowak wrote:

 On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote:

 On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:

 I agree it should have been done, not saying it's OK to break the process in
 some cases. I'm just explaining why it probably happened the way it did.


 Yes, it should have been done. We screwed up.


 It's time that we agree on/document an official deprecation approach and
 rigorously enforce it, making as few exceptions as possible.


I thought we had one:

1. warning
2. deprecation
3. error
4. removal
Apr 24 2015
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 25 April 2015 at 06:37:28 UTC, Walter Bright wrote:

 I thought we had one:

 1. warning
 2. deprecation
 3. error
 4. removal


Almost, but without warning stage. It caused lot of issues for no 
added value and most recent deprecations went through shorter 
cycle afair.
Apr 25 2015
prev sibling next sibling parent "grm" <gerhard.mueller gmsoft.at> writes:
On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:

 On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):


 -d is your enemy, If you remove that, there will be a clear 
 warning "Deprecation: variable XXX.S.FLAG_ON immutable field 
 with initializer should be static, __gshared, or an enum". You 
 decided to ignore and hide it, why the surprise about the 
 breakage?


+100
Apr 22 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/22/2015 01:36 PM, Dicebot wrote:

 
 -d is your enemy, If you remove that, there will be a clear warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
 should be static, __gshared, or an enum". You decided to ignore and hide
 it, why the surprise about the breakage?


Maybe using -d should itself emit a warning?
Apr 22 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 23 Apr 2015 00:23:06 +0200, Martin Nowak wrote:


 On 04/22/2015 01:36 PM, Dicebot wrote:

=20
 -d is your enemy, If you remove that, there will be a clear warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
 should be static, __gshared, or an enum". You decided to ignore and
 hide it, why the surprise about the breakage?


=20
 Maybe using -d should itself emit a warning?


you can't protect people from themselves.=
Apr 22 2015
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 April 2015 at 00:23, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 04/22/2015 01:36 PM, Dicebot wrote:

 -d is your enemy, If you remove that, there will be a clear warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
 should be static, __gshared, or an enum". You decided to ignore and hide
 it, why the surprise about the breakage?


 Maybe using -d should itself emit a warning?


People might start asking for a compiler switch to turn of -d emitting
a warning...  :o)
Apr 23 2015
prev sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:

 On 04/22/2015 01:36 PM, Dicebot wrote:

 
 -d is your enemy, If you remove that, there will be a clear 
 warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with 
 initializer
 should be static, __gshared, or an enum". You decided to 
 ignore and hide
 it, why the surprise about the breakage?


 Maybe using -d should itself emit a warning?


This does not help (-d is not problem), you can not protect me 
from myself. Real problem is that changing semantics never end up 
well. If I skip 2.066(and many versions before) version of D 
compiler, I even do not get any deprecation or warning message. 
Original code is 2 years old (which should be legacy code for 
someone).

Even if this kind of change take more time, what time is enought?
2 years, 5 years, 10 years? What about old stackoverflow answers? 
IMHO it is impossible to make this right. We only can try to make 
it right as possible. And in this case I do not think we made it 
:(.
Apr 23 2015
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 23 April 2015 at 08:11:50 UTC, Daniel Kozak wrote:

 On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:

 On 04/22/2015 01:36 PM, Dicebot wrote:

 
 -d is your enemy, If you remove that, there will be a clear 
 warning
 "Deprecation: variable XXX.S.FLAG_ON immutable field with 
 initializer
 should be static, __gshared, or an enum". You decided to 
 ignore and hide
 it, why the surprise about the breakage?


 Maybe using -d should itself emit a warning?


 This does not help (-d is not problem), you can not protect me 
 from myself. Real problem is that changing semantics never end 
 up well. If I skip 2.066(and many versions before) version of D 
 compiler, I even do not get any deprecation or warning message. 
 Original code is 2 years old (which should be legacy code for 
 someone).


Skipping compiler versions during upgrade is asking for trouble 
too. I don't remember it being done even for GCC - production 
users always do it one major version step at a time. And C was 
not supposed to change at all.
Apr 23 2015
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, April 22, 2015 11:28:43 Daniel Kozak via Digitalmars-d wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):
 OK

 dmd (2.067, -debug -d):
 core.exception.AssertError main.d(24): Assertion failure
 ----------------
 ./main() [0x46413f]
 ./main(_Dmain+0x86) [0x449996]
 ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
 [0x467d53]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).tryExec(scope void delegate())+0x2a)
 [0x467ca6]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).runAll()+0x30) [0x467d0c]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).tryExec(scope void delegate())+0x2a)
 [0x467ca6]
 ./main(_d_run_main+0x1dc) [0x467c20]
 ./main(main+0x17) [0x464157]
 /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]


What code does this? You just showed the output, not the code that triggers
the problem.

- Jonathan M Davis
Apr 22 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 22 April 2015 at 14:13:01 UTC, Jonathan M Davis 
wrote:

 On Wednesday, April 22, 2015 11:28:43 Daniel Kozak via 
 Digitalmars-d wrote:

 This code compile fine under both versions:

 dmd (2.066, -debug -d):
 OK

 dmd (2.067, -debug -d):
 core.exception.AssertError main.d(24): Assertion failure
 ----------------
 ./main() [0x46413f]
 ./main(_Dmain+0x86) [0x449996]
 ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
 [0x467d53]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).tryExec(scope void delegate())+0x2a)
 [0x467ca6]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).runAll()+0x30) [0x467d0c]
 ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
 function(char[][])*).tryExec(scope void delegate())+0x2a)
 [0x467ca6]
 ./main(_d_run_main+0x1dc) [0x467c20]
 ./main(main+0x17) [0x464157]
 /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]


 What code does this? You just showed the output, not the code 
 that triggers
 the problem.

 - Jonathan M Davis


http://forum.dlang.org/post/khhgviigmymiyitvnfkh forum.dlang.org
Apr 22 2015
prev sibling parent "w0rp" <devw0rp gmail.com> writes:
You really should pay attention to the deprecation messages. 
immutable was unfortunately used as if it was a manifest constant 
before, but it ought to be a member of a struct, and that 
behaviour is changing. There's been a deprecation message there 
for a while, now the behaviour is changing, and eventually you'll 
be able to create immutable members of structs without any 
warnings, as it will just use the new behaviour.
Apr 22 2015