www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Compiler Bug?

reply Bottled Gin <Gin Bottle.corked> writes:
I am using LDC-1.14-beta1, but tried with LDC-1.12 as well. This 
bug totally freaked me out. It took me over a week to reduce to 
this level from my forty thousand line project (thanks dustmite).

I am compiling a static library and then linking to the file 
having main function. I get assert for a class method which I am 
not calling anywhere. I am posting it in the forum so that I can 
get some help reducing it further. Right now it is < 100 lines, 
but spread over 9 files.

I have put the code on github. -> 
https://github.com/dsnippet/ldcbug

To test, clone the git repo, have LDC in path and make run.

Please help.
Jan 28
next sibling parent Bottled Gin <Gin Bottle.corked> writes:
This is what I get on my Ubunto 16.04 machine. Strange that the 
code never calls func1!

core.exception.AssertError grault.d(6): func1 was never called
Jan 28
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
huh it worked for me, but I am on a different ldc version. is it 
easy for you to update that?
Jan 28
next sibling parent Nemanja =?UTF-8?B?Qm9yacSH?= <dlang nemanjaboric.com> writes:
On Monday, 28 January 2019 at 21:00:42 UTC, Adam D. Ruppe wrote:
 huh it worked for me, but I am on a different ldc version. is 
 it easy for you to update that?
Fails for me in the same way as OP described. ldc: stable 1.13.0 Interestingly, if you call func7 and not func8 from func, you get stack overflow (func starts calling itself). You can reduce the levels of inheritance, but foo seems to be important.
Jan 28
prev sibling parent reply Bottled Gin <Gin Bottle.corked> writes:
On Monday, 28 January 2019 at 21:00:42 UTC, Adam D. Ruppe wrote:
 huh it worked for me, but I am on a different ldc version. is 
 it easy for you to update that?
I am using LDC-1.14.0-beta1. The only way to upgrade is to compile from source. What version is yours?
Jan 28
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 28 January 2019 at 23:57:09 UTC, Bottled Gin wrote:
 I am using LDC-1.14.0-beta1. The only way to upgrade is to 
 compile from source.
 What version is yours?
Mine is actually older, 1.12-beta but I was wrong; it actually did happen, I was just compiling it wrong. Sorry, my mistake. So yeah, bug confirmed. Strange: it only happens with separate compilation. If you compile directly with ldc2 *.d, it all works. The vtable seems to be wrapping around. So when we call func7, it goes back to func, func8 goes to func1, if we were to add a func9, it goes to func2. ldc2 *.d # works correctly for i in *.d; do ldc2 -c $i; done; ldc2 *.o # produces the wrong code huh, this is totally weird. And it happens with dmd as well as ldc, so it isn't a compiler specific thing; we have a frontend bug. I gotta run, will look more later though.
Jan 28
parent reply Nemanja Boric <dlang nemanjaboric.com> writes:
On Tuesday, 29 January 2019 at 00:17:22 UTC, Adam D. Ruppe wrote:
 On Monday, 28 January 2019 at 23:57:09 UTC, Bottled Gin wrote:
 [...]
Mine is actually older, 1.12-beta but I was wrong; it actually did happen, I was just compiling it wrong. Sorry, my mistake. So yeah, bug confirmed. Strange: it only happens with separate compilation. If you compile directly with ldc2 *.d, it all works. The vtable seems to be wrapping around. So when we call func7, it goes back to func, func8 goes to func1, if we were to add a func9, it goes to func2. ldc2 *.d # works correctly for i in *.d; do ldc2 -c $i; done; ldc2 *.o # produces the wrong code huh, this is totally weird. And it happens with dmd as well as ldc, so it isn't a compiler specific thing; we have a frontend bug. I gotta run, will look more later though.
I suggest to open the issue in bugzilla as well. This post will soon disappear from the first page.
Jan 30
parent Bottled Gin <Gin Bottle.corked> writes:
 I suggest to open the issue in bugzilla as well. This post will 
 soon disappear from the first page.
Reducing a similar case in dustmite. Hopefully, I will have the reduced test by tomorrow or day after. Will file a bug after that. BTW, looks like it has something to do with selective import in foo.d: import corge: corge; I can confirm that the bug disappears (even in my 40000 line project) if I replace it with: import corge; Not that I do not use selective imports elsewhere. But a combination of this selective import with some other factors seems to cause the bug. Any clues?
Jan 30
prev sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
What an amazing issue! I'm in love!

I've given you a PR to reduce the test further. The issue is 
related to the circular import between foo and qux, and the fact 
that qux forces foo to do ~something~ with its vtable to enable 
its use in the hashmap.
Jan 31
parent reply Bottled Gin <Gin Bottle.corked> writes:
On Thursday, 31 January 2019 at 09:41:42 UTC, FeepingCreature 
wrote:
 What an amazing issue! I'm in love!

 I've given you a PR to reduce the test further. The issue is 
 related to the circular import between foo and qux, and the 
 fact that qux forces foo to do ~something~ with its vtable to 
 enable its use in the hashmap.
Thanks, I merged in your PR. I managed to minimize another issue which I believe could be related. This time it is a compile time error which occurs only when compiling separately. Compiling the modules together does not result in Error. $ git clone https://github.com/dsnippet/circular.git $ cd circular $ ldc2 -c foo.d With LDC-1.14-beta1, I get: fred.d(4): Error: function void fred.qux!(bar).qux.thunk() does not override any function, did you mean to override void foo.foo.thunk()? fred.d(7): Error: template instance `fred.qux!(bar)` error instantiating
Jan 31
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 31 January 2019 at 17:31:22 UTC, Bottled Gin wrote:
 On Thursday, 31 January 2019 at 09:41:42 UTC, FeepingCreature 
 wrote:
 What an amazing issue! I'm in love!

 I've given you a PR to reduce the test further. The issue is 
 related to the circular import between foo and qux, and the 
 fact that qux forces foo to do ~something~ with its vtable to 
 enable its use in the hashmap.
Thanks, I merged in your PR. I managed to minimize another issue which I believe could be related. This time it is a compile time error which occurs only when compiling separately. Compiling the modules together does not result in Error. $ git clone https://github.com/dsnippet/circular.git $ cd circular $ ldc2 -c foo.d With LDC-1.14-beta1, I get: fred.d(4): Error: function void fred.qux!(bar).qux.thunk() does not override any function, did you mean to override void foo.foo.thunk()? fred.d(7): Error: template instance `fred.qux!(bar)` error instantiating
I highly recommend opening issues for both bugs in Bugzilla (when it doesn't work with dmd either) or LDC's GitHub as this post will quickly disappear from the front page.
Feb 01
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 1 February 2019 at 21:13:51 UTC, Seb wrote:
 I highly recommend opening issues for both bugs in Bugzilla 
 (when it doesn't work with dmd either) or LDC's GitHub as this 
 post will quickly disappear from the front page.
it is definitely a frontend bug, it affects dmd too. Only on separate compilation though.
Feb 01
parent reply Bottled Gin <Gin Bottle.corked> writes:
On Friday, 1 February 2019 at 21:51:04 UTC, Adam D. Ruppe wrote:
 On Friday, 1 February 2019 at 21:13:51 UTC, Seb wrote:
 I highly recommend opening issues for both bugs in Bugzilla 
 (when it doesn't work with dmd either) or LDC's GitHub as this 
 post will quickly disappear from the front page.
it is definitely a frontend bug, it affects dmd too. Only on separate compilation though.
Not just separate compilation, I am facing issues when compiling in one go as well. I am trying to reduce such a testcase. Will file bug soon. Just want to make sure that all dimensions are covered.
Feb 01
parent reply Bottled Gin <gin bottle.com> writes:
 Not just separate compilation, I am facing issues when 
 compiling in one go as well. I am trying to reduce such a 
 testcase.
Alright. I reduced the circular dependency issue when compiling d files together. To reproduce: $ git clone https://github.com/dsnippet/deploopbug.git $ for i in *.d; do ldc2 -c $i; done # compiles without issue $ ldc2 -c seq.d foo.d frop.d pol.d trump.d bar.d baz.d # no issue $ ldc2 -c foo.d frop.d pol.d trump.d bar.d baz.d seq.d frop.d(5): Error: function bool frop.frop.func(foo rhs, bar bee) does not override any function, did you mean to override bool foo.foo.func(foo rhs, bar bee)? DMD also behaves similarly. Compiles without error when d modules compiled separately. No error when compiling files together in one order. With another order, the compiler fails.
 Will file bug soon. Just want to make sure that all dimensions 
 are covered.
https://issues.dlang.org/show_bug.cgi?id=19655 https://issues.dlang.org/show_bug.cgi?id=19656 https://issues.dlang.org/show_bug.cgi?id=19657
Feb 06
parent reply Bottled Gin <gin bottle.com> writes:
 https://issues.dlang.org/show_bug.cgi?id=19655
 https://issues.dlang.org/show_bug.cgi?id=19656
 https://issues.dlang.org/show_bug.cgi?id=19657
Turns out all these are regressions. All these tests work with DMD release 2.74.1. And they all fail with 2.75.0 and later.
Feb 12
parent reply Bottled Gin <gin bottle.com> writes:
On Tuesday, 12 February 2019 at 10:31:12 UTC, Bottled Gin wrote:
 https://issues.dlang.org/show_bug.cgi?id=19655
 https://issues.dlang.org/show_bug.cgi?id=19656
 https://issues.dlang.org/show_bug.cgi?id=19657
Turns out all these are regressions. All these tests work with DMD release 2.74.1. And they all fail with 2.75.0 and later.
I mean work with 2.074.1 and fail with 2.075.0. Is there some wiki article that can help me setup git bisect for DMD? I am on Linux.
Feb 12
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 12 February 2019 at 10:35:09 UTC, Bottled Gin wrote:
 On Tuesday, 12 February 2019 at 10:31:12 UTC, Bottled Gin wrote:
 https://issues.dlang.org/show_bug.cgi?id=19655
 https://issues.dlang.org/show_bug.cgi?id=19656
 https://issues.dlang.org/show_bug.cgi?id=19657
Turns out all these are regressions. All these tests work with DMD release 2.74.1. And they all fail with 2.75.0 and later.
I mean work with 2.074.1 and fail with 2.075.0. Is there some wiki article that can help me setup git bisect for DMD? I am on Linux.
https://github.com/CyberShadow/Digger should help you do what you want.
Feb 12
parent reply Bottled Gin <gin bottle.com> writes:
On Tuesday, 12 February 2019 at 11:09:48 UTC, Petar Kirov 
[ZombineDev] wrote:
 https://github.com/CyberShadow/Digger should help you do what 
 you want.
Thanks. Digger points me to a merge from another branch (which seems to have been deleted since), which actually pulls in about 400 PRs. It must be part of the release process. Do I need to review all these 400 pull requests to figure out?
Feb 12
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 12, 2019 at 05:01:04PM +0000, Bottled Gin via Digitalmars-d wrote:
 On Tuesday, 12 February 2019 at 11:09:48 UTC, Petar Kirov [ZombineDev]
 wrote:
 https://github.com/CyberShadow/Digger should help you do what you want.
Thanks. Digger points me to a merge from another branch (which seems to have been deleted since), which actually pulls in about 400 PRs. It must be part of the release process. Do I need to review all these 400 pull requests to figure out?
Shouldn't digger be able to narrow down those 400 PRs to something more manageable? There is no need to worry about branches being deleted; in git, branches are merely references to commits. As long as you have the git repo, you have all the information you need. All you have to do is to identify the branch point of the branch (`git log --graph --oneline` is your friend) and the tip of the branch, and digger should be able to bisect that range to something more manageable. T -- Question authority. Don't ask why, just do it.
Feb 12
parent reply Bottled Gin <gin bottle.com> writes:
On Tuesday, 12 February 2019 at 17:23:43 UTC, H. S. Teoh wrote:

 There is no need to worry about branches being deleted; in git, 
 branches are merely references to commits. As long as you have 
 the git repo, you have all the information you need. All you 
 have to do is to identify the branch point of the branch (`git 
 log --graph --oneline` is your friend) and the tip of the 
 branch, and digger should be able to bisect that range to 
 something more manageable.
Thanks Teoh, I was able to move forward using "git bisect" manually. The commit that breaks these tests is: commit fb315d03f0744b8406d31b9c106d3a42c0c178b3 Author: Walter Bright <walter walterbright.com> Date: Thu Mar 23 23:16:12 2017 -0700 refactor: move towards using semanticRun From the comment and the commits that follow, it is clear that this is first in a series of commits, though this commit itself is not too many lines of code. I do not understand what is happening in the code here. So either I need help or someone else needs to take this forward from here.
Feb 13
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 13, 2019 at 12:43:40PM +0000, Bottled Gin via Digitalmars-d wrote:
[...]
 Thanks Teoh, I was able to move forward using "git bisect" manually.
 
 The commit that breaks these tests is:
 
 commit fb315d03f0744b8406d31b9c106d3a42c0c178b3
 Author: Walter Bright <walter walterbright.com>
 Date:   Thu Mar 23 23:16:12 2017 -0700
 
     refactor: move towards using semanticRun
 
 From the comment and the commits that follow, it is clear that this is
 first in a series of commits, though this commit itself is not too
 many lines of code.
 
 I do not understand what is happening in the code here. So either I
 need help or someone else needs to take this forward from here.
[...] Now that you have the commit, all you need is a minimal test case that reproduces the problem. Put both in a bug report or add it to an existing bug, if one already exists, and one of the dmd devs should be able to take it from there. (Then post the link to the bug here and complain about it, and one of them should take notice. :-P) T -- Маленькие детки - маленькие бедки.
Feb 13
parent reply Bottled Gin <gin bottle.com> writes:
On Wednesday, 13 February 2019 at 16:16:20 UTC, H. S. Teoh wrote:
 On Wed, Feb 13, 2019 at 12:43:40PM +0000, Bottled Gin via 
 Digitalmars-d wrote: [...]
 Thanks Teoh, I was able to move forward using "git bisect" 
 manually.
 
 The commit that breaks these tests is:
 
 commit fb315d03f0744b8406d31b9c106d3a42c0c178b3
 Author: Walter Bright <walter walterbright.com>
 Date:   Thu Mar 23 23:16:12 2017 -0700
 
     refactor: move towards using semanticRun
 
 From the comment and the commits that follow, it is clear that 
 this is first in a series of commits, though this commit 
 itself is not too many lines of code.
 
 I do not understand what is happening in the code here. So 
 either I need help or someone else needs to take this forward 
 from here.
[...] Now that you have the commit, all you need is a minimal test case that reproduces the problem. Put both in a bug report or add it to an existing bug, if one already exists, and one of the dmd devs should be able to take it from there. (Then post the link to the bug here and complain about it, and one of them should take notice. :-P) T
Thanks for your help Teoh. I already reported 3 bugs earlier on this thread. I will be adding another test to issue 19655 soon. https://issues.dlang.org/show_bug.cgi?id=19655 https://issues.dlang.org/show_bug.cgi?id=19656 https://issues.dlang.org/show_bug.cgi?id=19657
Feb 13
parent Bottled Gin <gin bottle.com> writes:
On Wednesday, 13 February 2019 at 16:39:50 UTC, Bottled Gin wrote:
 Thanks for your help Teoh. I already reported 3 bugs earlier on 
 this thread. I will be adding another test to issue 19655 soon.

 https://issues.dlang.org/show_bug.cgi?id=19655
 https://issues.dlang.org/show_bug.cgi?id=19656
 https://issues.dlang.org/show_bug.cgi?id=19657
Added another failing test. This test does not involve assoc arrays. It is something to do with super class trait. https://github.com/dsnippet/traitSuperBug To reproduce the bug, compile foo.d $ dmd -c foo.d thud.d(4): Error: function void thud.Dap!int.Dap.thunk() does not override any function, did you mean to override void foo.Foo.thunk()? thud.d(7): Error: template instance `thud.Dap!int` error instantiating Will file another regression on bugzilla.
Feb 20