From dmd-internals at puremagic.com Fri Sep 23 19:52:11 2016 From: dmd-internals at puremagic.com (Martin Nowak via dmd-internals) Date: Sat, 24 Sep 2016 04:52:11 +0200 Subject: [dmd-internals] 14th planning Message-ID: <2323a3dd-bdbd-d0c3-83af-13901e7fb1d9@dawg.eu> Still on dmd-internals, while we're waiting for a D.internal newsgroup to be created. You may notice that we skipped the 13th ;). # Retro On one hand dconf, all the import/lookup changes, a bigger non-D project (written in D though), and some vacations kept me extremely busy and contributed to the heavy delay during 2.071.x. On the other hand I'm glad we've finished the language side of the big import/lookup transition w/ 2.071.2. The 2.071.x series is meant to be a stopgap for anyone updating his code and I want to try something "new". In case we find more import/lookup issues, fixes for those should target 2.071.x instead of stable so that we're able to make further 2.071.x point releases. # Planning - 2.072.x - The phobos people were hard-working and accumulated a huge amount of changes. [phobos/changelog.dd](https://github.com/dlang/phobos/blob/bf14b1897e62f996cfbf8fc99dae9cf3476b3dfc/changelog.dd) So as said earlier we're directly rushing to the next release beginning w/ a beta in about a week. - In case you have any partially finished work already merged into master, please make sure to either get that finished or revert it temporarily before we're merging master into stable (September 30th would be my targeted date for that). On a side node, we're also experimenting with feature branches ([dlang/dmd at newCTFE](https://github.com/dlang/dmd/tree/newCTFE)) to merge bigger features incrementally in multiple PRs. If that works for us, it should help to avoid releasing partially finished feature. - Next Month Development - [templated vector ops (arrayOp)](https://trello.com/c/TNCQ6xBk/171-templated-library-arrayop-implementation-also-fixes-issue-15619) Lot's of work already done, RPN support in dmd and a working (for simple things) generic arrayOp. Still need to talk to gdc/ldc developers whether they want to rely on auto-vectorization instead of SIMD intrinsics. - templated library AA (core.aa) [more core.aa feedback](https://trello.com/c/RDVhfCZR/235-more-core-aa-feedback), [finish core.aa implementation](https://trello.com/c/rgZ4Nd9g/236-finish-core-aa-implementation) We got some momentum to continue work on the core.aa proposal, see discussions in the [forum](http://forum.dlang.org/post/anhtpsftcedurgskfsgx at forum.dlang.org) and on [GitHub](https://github.com/dlang/druntime/pull/1282). Still want to get Walter into the discussion to check at least the planned language changes. - [Issue 11657 – Pass array literal to typesafe variadic argument on stack](https://issues.dlang.org/show_bug.cgi?id=11657) - [Issue 11658 – implicit conversion of associative array literal to (typesafe variadic) tuple array](https://issues.dlang.org/show_bug.cgi?id=11658) Interestingly the first one comes w/ a reference escaping hole, see [Issue 5212 – no escape analysis for typesafe variadic function arguments](https://issues.dlang.org/show_bug.cgi?id=5212), that nicely fits to the DIP25/1000 topic. - improve reliability of CI integration and install.sh script - -Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dmd-internals at puremagic.com Tue Sep 27 02:40:32 2016 From: dmd-internals at puremagic.com (Mathias Lang via dmd-internals) Date: Tue, 27 Sep 2016 11:40:32 +0200 Subject: [dmd-internals] Internal compiler error handling Message-ID: Hello DMD devs, Since we switched to DDMD, there has been a major regression hanging around: asserts are stripped out of the version we ship (except for assert(0)), because for performance reason we ship with `-release`. This can lead to very subtle and hard to spot bug in user code, and requiring someone to build a debug version of DMD in order to post a bug report is a clear red flag. There has been discussions on what to do with this, in this P.R. : https://github.com/dlang/dmd/pull/5716 One of the solution proposed by Martin was to provide a switch to allow `assert`. This has the disadvantage of still stripping `invariant` and `in`/`out` contracts, and might be confusing to user code. One other solution - which doesn't require a language change - would be to use exception for ICE (which are rare anyway), and provide a comprehensive handler at the top level to: - Provide a nice error message - Provide a dump of the code / AST that produced the error - Point to bugzilla, as suggested in a recent P.R. by Dicebot: https://github.com/dlang/dmd/pull/6103 Thoughts ? From dmd-internals at puremagic.com Wed Sep 28 05:19:48 2016 From: dmd-internals at puremagic.com (=?UTF-8?B?0JzQuNGF0LDQuNC7INCh0YLRgNCw0YjRg9C9?= via dmd-internals) Date: Wed, 28 Sep 2016 14:19:48 +0200 Subject: [dmd-internals] Internal compiler error handling In-Reply-To: References: Message-ID: <57012cda-9172-da70-3738-339cd6d5a23b@dicebot.lv> On 09/27/2016 11:40 AM, Mathias Lang via dmd-internals wrote: > Hello DMD devs, > > Since we switched to DDMD, there has been a major regression hanging > around: asserts are stripped out of the version we ship (except for > assert(0)), because for performance reason we ship with `-release`. > This can lead to very subtle and hard to spot bug in user code, and > requiring someone to build a debug version of DMD in order to post a bug > report is a clear red flag. It is actually worse than that because if any of non-assert(0) check fails, developer want even see any clear ICE - it may or may not crash in some random place later. Because of that issue we currently have no idea how many ICE issues may still remain in the frontend part. > There has been discussions on what to do with this, in this P.R. : > https://github.com/dlang/dmd/pull/5716 I must admit I was sure this PR got merged long time ago. The fact that Martin decided 5% performance is more important than risk of generating wrong code is worrying :( > One other solution - which doesn't require a language change - would be > to use exception for ICE (which are rare anyway) Would be interesting to check all usage of `assert` and see: a) how many of them protect from something truly bad b) are there many "real" asserts (i.e. not assert(0)) in general -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 480 bytes Desc: OpenPGP digital signature URL: From dmd-internals at puremagic.com Wed Sep 28 11:19:05 2016 From: dmd-internals at puremagic.com (Mathias Lang via dmd-internals) Date: Wed, 28 Sep 2016 20:19:05 +0200 Subject: [dmd-internals] Internal compiler error handling In-Reply-To: <57012cda-9172-da70-3738-339cd6d5a23b@dicebot.lv> References: <57012cda-9172-da70-3738-339cd6d5a23b@dicebot.lv> Message-ID: <3532a6be-cf3b-eb67-9596-8181974751c7@sociomantic.com> On 09/28/2016 02:19 PM, Михаил Страшун via dmd-internals wrote: > >> One other solution - which doesn't require a language change - would be >> to use exception for ICE (which are rare anyway) > Would be interesting to check all usage of `assert` and see: > > a) how many of them protect from something truly bad > b) are there many "real" asserts (i.e. not assert(0)) in general > > I'd say quite a lot: grep -nR "assert\b*(" src/*.d | grep -v "static assert" | grep -v "assert\b*(0)" | wc -l 1083 It is hard to investigate how many prevents bug, but I had a quick look and it's not a neglectible amount sadly.