[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #15 from Martin Nowak <code at dawg.eu> ---
(In reply to b2.temp from comment #14)
> (In reply to Martin Nowak from comment #13)
> > (In reply to b2.temp from comment #11)
> > > $ if [ -d kheops ]; then
> > > $     cd kheops
> > > $     git pull
> > > $     cd ..
> > > $ else
> > > $     git clone https://github.com/BBasile/kheops.git
> > > $ fi
> > > $ cd kheops/runnable
> > > $ dub default_alignment.d 
> > 
> > Mmh, apparently you don't see the problem w/ your test case, so I'm saying
> > this explicit.
> > The moment you add a new commit, or any of the your project's dependencies
> > gets updated, the bug might no longer be reproducible.
> 
> $ if ! [ -d kheops ]; then
> $     git clone https://github.com/BBasile/kheops.git
> $ fi
> $ 
> $ cd kheops
> $ git checkout a00f300c4281b2d4aaf95e7fabde48d3dc3816e9
> $ cd runnable
> $ dub default_alignment.d
> 
> > I've already spend a lot of time trying to reproduce this bug w/ your ever
> 
> So do I. I've manually compiled DMD and phobos about a hundred of times to
> find where default_alignment.d started not to work anymore. Also the
> (unfortunately) wrong reduction didn't pop from the magician hat.

I didn't mean to be unfriendly, it's just that such small formal problems eat a
lot of time.

> 'dub build --build=unittest' does nothing, you should have get  "Target is a
> library.

Nevermind, I always ran the default_alignment.d test as posted in comment 1.

> He's the author of the feature.

That's not development in any organization should work, exactly b/c people can 

> I have many others small applications like "default_alignment.d" that I run
> to track possible breakage. Once again I don't understand what you are
> trying to tell me. With DMD 2.071.2 they are all compiled, they run all.

Well, then it's a regression, but if you look at comment 6, it's rather
confusing to follow. Last time I tested the project wasn't compiling with any
version between 2.069 and 2.071 (see comment 8).

> > Lazy alias analysis is a huge improvement for compile times, 
> 
> Certainly.
> 
> > so we won't drop it light-hearted.
> 
> So don't drop it and make your release but keep in mind that there's an
> issue. Soon or later it will show the tip of its nose again.

Well that's why I'm spending time here. It's not even sure that the lazy alias
is the cause of this problem.

--