On Wednesday, 17 February 2016 at 02:23:52 UTC, Ali Çehreli wrote:
> Since a static array must consist of .init values to begin with, every move into its members must also trigger its destructor if the type has elaborate destructor.

Oof. This strikes me as a "gotcha", that this happens even with @disable this() as opposed to a compiler error. Is this only for static arrays, or are there other places @disable this() is silently ignored?

> This is what I've discovered:

Ok, I think that pretty much explains the behavior I was seeing in the reduced case. Thanks -- that's helpful to know!

The downside is that it really indicates that I didn't reduce my buggy program properly. I'll hold out for the live-object-destructor-call fix to see whether that corrects my problem; I can just leak resources until then :).

On Wednesday, 17 February 2016 at 02:44:04 UTC, Matt Elkins wrote:
> On Wednesday, 17 February 2016 at 02:23:52 UTC, Ali Çehreli wrote:
>> [...]
>
> Oof. This strikes me as a "gotcha", that this happens even with @disable this() as opposed to a compiler error. Is this only for static arrays, or are there other places @disable this() is silently ignored?
>
>> [...]
>
> Ok, I think that pretty much explains the behavior I was seeing in the reduced case. Thanks -- that's helpful to know!
>
> The downside is that it really indicates that I didn't reduce my buggy program properly. I'll hold out for the live-object-destructor-call fix to see whether that corrects my problem; I can just leak resources until then :).

BTW, you can try the nighly build which should include the bug fix:
http://dlang.org/download.html

dmd's behaviour is too confusing to accept. :) Filed:

  https://issues.dlang.org/show_bug.cgi?id=15694

Ali

On Wednesday, 17 February 2016 at 07:10:15 UTC, ZombineDev wrote:
>> The downside is that it really indicates that I didn't reduce my buggy program properly. I'll hold out for the live-object-destructor-call fix to see whether that corrects my problem; I can just leak resources until then :).

So I've reduced it more properly now, and am 98% sure I've just got another manifestation of that same bug.

> BTW, you can try the nighly build which should include the bug fix:
> http://dlang.org/download.html

I tried this, and got the same issue. Actually, I was still able to reproduce the original reported issue as well, which leads me to believe either the bug was not actually fixed or (and this is more likely) I screwed something up with my install. Do I need to do anything special to install a nightly build (I'm on Windows)? My "install" procedure was to move my dmd2 folder, verify that compilation now fails since there is no compiler installed, and then copy in the nightly build's dmd2 folder over the original path. Compilation then succeeds (but the bug still manifests).

That was running through my IDE (IntelliJ with the D language plugin), and then in turn through DUB. To remove variables, I also tried running dmd directly on the test file: dmd.exe test.d -unittest -main. This compiled but also reproduced the bug.

I guess the other possibility is that a patch was made and the issue marked resolved, but the patch hasn't been folded into the nightly build. I have no idea how dmd's patch/build/CI process works, so I don't know whether that is a real possibility.

On 17.02.2016 17:36, Matt Elkins wrote:
> I tried this, and got the same issue. Actually, I was still able to
> reproduce the original reported issue as well, which leads me to believe
> either the bug was not actually fixed or (and this is more likely) I
> screwed something up with my install. Do I need to do anything special
> to install a nightly build (I'm on Windows)?

For reference, link to the issue:
https://issues.dlang.org/show_bug.cgi?id=15661

As you can see on the bugzilla page, the fix was pushed to the 'stable' branch. But nightlies are probably built from 'master'. So the fix isn't in the nightlies until 'stable' gets merged into 'master'. At the latest, that should happen again with the 2.071 release.

You can build a 'stable' dmd from git. I just did that and I can say that the test code for issue 15661 now prints

----
HERE1a
HERE1b
HERE2
----

which seems to be the correct output, indicating that the issue got fixed.

However, the code from this thread still prints

----
Before 8
Before 1
Foo being destroyed: 0
Before 2
Foo being destroyed: 0
Before 3
Foo being destroyed: 0
After Foo construction
About to lose scope
Foo being destroyed: 0
Foo being destroyed: 3
Foo being destroyed: 2
Foo being destroyed: 1 

Foo being destroyed: 8
----

So, different issue?

On 02/17/2016 11:37 AM, anonymous wrote:

> However, the code from this thread still prints
>
> ----
> Before 8
> Before 1
> Foo being destroyed: 0
> Before 2
> Foo being destroyed: 0
> Before 3
> Foo being destroyed: 0
> After Foo construction
> About to lose scope
> Foo being destroyed: 0
> Foo being destroyed: 3
> Foo being destroyed: 2
> Foo being destroyed: 1
> Foo being destroyed: 8
> ----
>
> So, different issue?

I thought so and opened the following yesterday:

  https://issues.dlang.org/show_bug.cgi?id=15694

Ali

On Wednesday, 17 February 2016 at 16:36:35 UTC, Matt Elkins wrote:
> On Wednesday, 17 February 2016 at 07:10:15 UTC, ZombineDev wrote:
>>> The downside is that it really indicates that I didn't reduce my buggy program properly. I'll hold out for the live-object-destructor-call fix to see whether that corrects my problem; I can just leak resources until then :).
>
> So I've reduced it more properly now, and am 98% sure I've just got another manifestation of that same bug.
>
>> BTW, you can try the nighly build which should include the bug fix:
>> http://dlang.org/download.html
>
> I tried this, and got the same issue. Actually, I was still able to reproduce the original reported issue as well, which leads me to believe either the bug was not actually fixed or (and this is more likely) I screwed something up with my install. Do I need to do anything special to install a nightly build (I'm on Windows)? My "install" procedure was to move my dmd2 folder, verify that compilation now fails since there is no compiler installed, and then copy in the nightly build's dmd2 folder over the original path. Compilation then succeeds (but the bug still manifests).
>
> That was running through my IDE (IntelliJ with the D language plugin), and then in turn through DUB. To remove variables, I also tried running dmd directly on the test file: dmd.exe test.d -unittest -main. This compiled but also reproduced the bug.
>
> I guess the other possibility is that a patch was made and the issue marked resolved, but the patch hasn't been folded into the nightly build. I have no idea how dmd's patch/build/CI process works, so I don't know whether that is a real possibility.

Sorry for the confusion. The bug was indeed fixed in the stable branch, however the stable branch is not yet merged into master, from which the nightly builds are packaged.
You should be able to test it with a nightly build probably within 1 or 2 days after you get a "Commits pushed to master" notification on the bugzilla issue [1].

[1]: https://issues.dlang.org/show_bug.cgi?id=15661