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.

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.

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.

> 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

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

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.

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.

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?

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.

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.