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 2019
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 2019
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 2019
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 2019
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 2019
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.



for i in *.d; do ldc2 -c $i; done;



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 2019
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.



 for i in *.d; do ldc2 -c $i; done;



 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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


$ 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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019