www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta 2.072.0-b2

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Second beta for the 2.072.0 release.

We've fixed quite a few regressions, but some issues are still open and
there will be third beta before the release.
Most notably we've fixed building of dmd on OSX, so you should now be
able to test the beta using brew.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.072.0.html

See the following links for all changes between 2.072.0-b1 and 2.072.0-b2.

https://github.com/D-Programming-Language/dmd/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/druntime/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/phobos/compare/v2.072.0-b1...v2.072.0-b2
https://github.com/D-Programming-Language/dlang.org/compare/v2.072.0-b1...v2.072.0-b2

Please report any bugs at https://issues.dlang.org.

-Martin
Oct 09 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
Which branch changelog content is generated from?
Oct 09 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote:

 Which branch changelog content is generated from?


Stable, the changelog is also included in the docs that are in 
the packages.
I do merge stable back into master to publish them though.
Oct 09 2016
parent Dicebot <public dicebot.lv> writes:
On Sunday, 9 October 2016 at 22:01:31 UTC, Martin Nowak wrote:

 On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote:

 Which branch changelog content is generated from?


 Stable, the changelog is also included in the docs that are in 
 the packages.
 I do merge stable back into master to publish them though.


I am confused in that case. What shall I do to replace 
http://dlang.org/changelog/2.072.0.html#dash_safe with my changes 
from https://github.com/dlang/dmd/blob/stable/changelog.dd ?
Oct 10 2016
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
There is an error [1] (caused by [2]) in taggedalgebraic, because void 
initializers for pointer types are now invalid in safe code. The 
question now is, is there any workaround that can be done in the 
library, or will every library user have to fix this?

Of course, the new error is more restrictive than it should be, namely 
if the uninitialized pointer field gets written before the first read, 
it would still be safe.

[1]: 
https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L280
[2]: 
https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L56
Oct 10 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:

 Of course, the new error is more restrictive than it should be, 
 namely if the uninitialized pointer field gets written before 
 the first read, it would still be safe.


That's surprising b/c void initializers for struct fields didn't 
use to work.
I need to research the intent behind this to say sth. detailed, 
though usually an shouldn't break working code, only deprecate it.
Oct 10 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.10.2016 um 12:20 schrieb Martin Nowak:

 On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:

 Of course, the new error is more restrictive than it should be, namely
 if the uninitialized pointer field gets written before the first read,
 it would still be safe.


 That's surprising b/c void initializers for struct fields didn't use to
 work.


Hm, thanks for the hint - if that's still the case, that leads to the 
very simple workaround of simply removing the "= void". Would have been 
nice in theory to have real void initialization of course, plus it was 
there for working around that (fixed?) issue with slow compilation times 
for large static arrays, but there is probably no real reason now to 
keep it.


 I need to research the intent behind this to say sth. detailed, though
 usually an shouldn't break working code, only deprecate it.
Oct 10 2016
next sibling parent Martin Nowak <code dawg.eu> writes:
On Monday, 10 October 2016 at 10:45:37 UTC, Sönke Ludwig wrote:

 Would have been nice in theory to have real void initialization 
 of course, plus it was there for working around that (fixed?) 
 issue with slow compilation times for large static arrays, but 
 there is probably no real reason now to keep it.


Here is the ER for using `= void` field initializers.
[Issue 11331 – Inefficient initialization of struct with members 
= void](https://issues.dlang.org/show_bug.cgi?id=11331)
Oct 10 2016
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.10.2016 um 12:45 schrieb Sönke Ludwig:

 Am 10.10.2016 um 12:20 schrieb Martin Nowak:

 On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:

 Of course, the new error is more restrictive than it should be, namely
 if the uninitialized pointer field gets written before the first read,
 it would still be safe.


 That's surprising b/c void initializers for struct fields didn't use to
 work.


 Hm, thanks for the hint - if that's still the case, that leads to the
 very simple workaround of simply removing the "= void". Would have been
 nice in theory to have real void initialization of course, plus it was
 there for working around that (fixed?) issue with slow compilation times
 for large static arrays, but there is probably no real reason now to
 keep it.


 I need to research the intent behind this to say sth. detailed, though
 usually an shouldn't break working code, only deprecate it.




Okay, I stumbled over another occurrence of this:

Bugzilla 16195: delete should be  system
   <- This makes it impossible to use `scope` variables in  safe scopes. 
The whole scope/function needs to be marked trusted now.

Bugzilla 14496: void initialization of member with indirections must not 
be  safe
   <- This makes it impossible to use std.typecons.scoped as an 
alternative, because it requires void initialization due to its disabled 
default constructor, or it would again affect the  safety of the whole 
surrounding scope.

I think both need to be adjusted to use a deprecation warning instead of 
an error. But the first one in conjunction with `scope` variables should 
be legal anyway, as long as the variable doesn't leave the scope (e.g. 
DIP1000). Maybe it makes sense to lower this to "scope (exit) () 
 trusted { delete var; } ();" instead of "scope (exit) delete var;" for 
now (making sure that the stack allocation optimization still works).
Oct 12 2016
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 9 October 2016 at 13:24:19 UTC, Martin Nowak wrote:

 Second beta for the 2.072.0 release.

 We've fixed quite a few regressions, but some issues are still 
 open and
 there will be third beta before the release.
 Most notably we've fixed building of dmd on OSX, so you should 
 now be
 able to test the beta using brew.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.072.0.html

 See the following links for all changes between 2.072.0-b1 and 
 2.072.0-b2.

 https://github.com/D-Programming-Language/dmd/compare/v2.07
.0-b1...v2.072.0-b2 https://github.com/D-Programming-Language/druntime/compare/v2.07
.0-b1...v2.072.0-b2 https://github.com/D-Programming-Language/phobos/compare/v2.07
.0-b1...v2.072.0-b2 https://github.com/D-Programming-Language/dlang.org/compare/v2.072.0-b1...v2.072.0-b2

 Please report any bugs at https://issues.dlang.org.

 -Martin


Any news on the front of 
https://issues.dlang.org/show_bug.cgi?id=16574 ?
This is a blocker. Last week week I've discovered that it's 
actually a regression that has even more regressed...so at least 
if we could come back to the previous level of regression this 
would also mean "situation unblocked".
Oct 10 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 10 October 2016 at 10:06:25 UTC, Basile B. wrote:

 Any news on the front of 
 https://issues.dlang.org/show_bug.cgi?id=16574 ?


It's on our heap and will be addressed soon.
Please look at our trello board.
https://trello.com/b/XoFjxiqG/active
Oct 10 2016
parent ag0aep6g <anonymous example.com> writes:
On 10/10/2016 12:28 PM, Martin Nowak wrote:

 It's on our heap and will be addressed soon.
 Please look at our trello board.
 https://trello.com/b/XoFjxiqG/active


These two 2.072 regressions seem to be missing from Trello:

https://issues.dlang.org/show_bug.cgi?id=16013
https://issues.dlang.org/show_bug.cgi?id=16273
Oct 10 2016