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

This problem appears only from DMD 2.072.0-b1 and under linux x86-64. You should have the development version of x11, freetype and cairo to test (otherwise you'll get linker errors, but that's not the point) 1. place you in a temporary folder 2. create a shell script with ========================== git clone https://github.com/BBasile/kheops.git cd kheops/runnable dub default_alignment.d ========================== 3. execute this script and you should get: > ../src/kheops/control.d(1866,1): Error: class kheops.control.Control cannot implicitly generate a default ctor when base class kheops.control.CustomControl is missing a default ctor > ../src/kheops/styles.d(28,5): while looking for match for PublishedObjectArray!(Style) > ../src/kheops/control.d(2207,19): Error: function kheops.control.OsWindow.procShow does not override any function > ../src/kheops/control.d(2219,19): Error: function kheops.control.OsWindow.procHide does not override any function > ../src/kheops/control.d(2552,25): Error: function kheops.control.OsWindow.isPointInside does not override any function > ../src/kheops/control.d(2557,25): Error: function kheops.control.OsWindow.repaint does not override any function > ../src/kheops/control.d(2561,24): Error: function kheops.control.OsWindow.caption does not override any function > ../src/kheops/control.d(2575,26): Error: function kheops.control.OsWindow.caption does not override any function > ../src/kheops/control.d(2577,24): Error: function kheops.control.OsWindow.height does not override any function > ../src/kheops/control.d(2590,25): Error: function kheops.control.OsWindow.height does not override any function > ../src/kheops/control.d(2592,24): Error: function kheops.control.OsWindow.width does not override any function > ../src/kheops/control.d(2605,25): Error: function kheops.control.OsWindow.width does not override any function > ../src/kheops/control.d(2607,24): Error: function kheops.control.OsWindow.left does not override any function > ../src/kheops/control.d(2622,25): Error: function kheops.control.OsWindow.left does not override any function > ../src/kheops/control.d(2624,24): Error: function kheops.control.OsWindow.top does not override any function > ../src/kheops/control.d(2639,25): Error: function kheops.control.OsWindow.top does not override any function > ../src/kheops/control.d(2842,19): Error: function kheops.control.MenuItem.updateFromAction does not override any function > ../src/kheops/control.d(2852,19): Error: function kheops.control.MenuItem.procMouseEnter does not override any function > ../src/kheops/control.d(2860,19): Error: function kheops.control.MenuItem.procMouseLeave does not override any function > ../src/kheops/control.d(2878,19): Error: function kheops.control.MenuItem.paint does not override any function > ../src/kheops/control.d(2937,19): Error: function kheops.control.CustomMenuWindow.unsetFocus does not override any function 4. (optional) Try 1/2/3 with 2.071.2: no problem (or just the linker messages). Apologies for this unpleasant report but I cannot provide more simple.

Reproduced the override errors w/ https://github.com/BBasile/kheops/commit/2f99686d346c291e1cfbe6e1412373d5cc1a385c. I don't get the error about the default ctor (might have been fixed in the meantime).

The culprit is this PR https://github.com/dlang/dmd/pull/5690

What happens is that an alias declaration inside a class creates a silent error (this is a second issue). When the alias is put out of the class the "real" error appears before those related to overriding. The project is updated https://github.com/BBasile/kheops/commit/c9522681ee5ffd3d6d4bb298d4a5597bcbb1d510 From now, to see the regression just clone, "cd kheops" and "dub".

(In reply to b2.temp from comment #3) > What happens is that an alias declaration inside a class creates a silent > error (this is a second issue). Can you file a report for that one with an example, please?

In a first time the good new is that I have a reduction: interface Desc {} class Bug(T): Desc if (is(T : Desc)) {} alias Type = Bug!Bar; class Bar: Desc { Type a; void test(){} } class Baz: Bar { override void test(){} } void main() { Bar b = new Bar; }

More information: Today I've reinstalled dmd 2.071.2 and bad news: the short example posted yesterday neither compiles with 2.071.2, unless the alias declaration is put in class Bar, which leads to think that there might be an other regression.

Smells like due to the lazy alias, semantic analysis of the base class is unfinished before checking the derived class' overload.

Well your code doesn't build with any of the past versions of the compiler, b/c of the template PublishedObjectArray!(CustomControl) being recursively used in a field of CustomControl. Can you provide any version of your software that correctly works w/ a previous version, but fails to compile now?

(In reply to Martin Nowak from comment #8) > Well your code doesn't build with any of the past versions of the compiler, > b/c of the template PublishedObjectArray!(CustomControl) being recursively > used in a field of CustomControl. > Can you provide any version of your software that correctly works w/ a > previous version, but fails to compile now? done, the alias must be moved in CustomControl. But it means that the reduction is also invalid. What's really sure is the PR that introduced the regression, 5690.

Just tested https://github.com/BBasile/kheops/commit/a00f300c4281b2d4aaf95e7fabde48d3dc3816e9. This commit did build with 2.070.2, 2.071.2, and still builds with 2.072.0-b2. Also dub test does pass with 2.071.2 and 2.072.0-b2, so this doesn't show any regression. If OTOH the recursive alias is declared outside of the class, all versions fail to compile. I went back and tested https://github.com/BBasile/kheops/commit/2f99686d346c291e1cfbe6e1412373d5cc1a385c which now also passes tests. Have you fixed some upstream library (e.g. iz)? I think all the override errors were just follow-up errors from a semantic analysis failure for the class or it's base class (e.g. due to the recursive alias). For your next bug report, please properly document all code involved or even provide a zip file here. Of course, at best you succeed to reduce the test case.

The regression is still there (b2). Now that the alias is back inside the class a derived must be instantiated in order to trigger the error. So the procedure to see it is like in the first post: $ 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 I think that you did not see it because the unittest config does nothing (it's a static library).

By the way Mr Nowak, I like to see how you're involved. But for this particular regression, maybe Kenji Hara could get in... If at a certain point he's not able to fix the new compiler feature: https://dlang.org/changelog/2.072.0.html#deferred_alias Then let's revert this feature until he has the time to work on it.

(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. I've already spend a lot of time trying to reproduce this bug w/ your ever moving example. So please make sure that bug reports use "permalinks" including the commit hash and dub.selections.json. > I think that you did not see it because the unittest config does nothing > (it's a static library). I ran dub build, if I recall correctly. (In reply to b2.temp from comment #12) > By the way Mr Nowak, I like to see how you're involved. But for this > particular regression, maybe Kenji Hara could get in... Unlikely, he is hardly nowadays. > If at a certain point he's not able to fix the new compiler feature: > > https://dlang.org/changelog/2.072.0.html#deferred_alias > > Then let's revert this feature until he has the time to work on it. Well, your code involves a recursive template, and it's not clear whether it's actually possible to be compiled. Lazy alias analysis is a huge improvement for compile times, so we won't drop it light-hearted.

(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. > moving example. So please make sure that bug reports use "permalinks" > including the commit hash and dub.selections.json. > > > I think that you did not see it because the unittest config does nothing > > (it's a static library). > > I ran dub build, if I recall correctly. 'dub build --build=unittest' does nothing, you should have get "Target is a library. Skipping execution." I don't know what you are trying to tell me here...anyway this is pointless because there's no unittest in this library. The only unittest were only used to make static checks related to manual memory management. > (In reply to b2.temp from comment #12) > > By the way Mr Nowak, I like to see how you're involved. But for this > > particular regression, maybe Kenji Hara could get in... > > Unlikely, he is hardly nowadays. He's the author of the feature. I don't even understand why this is you that handle all the dirty work with the many regressions of this pre-release. > > If at a certain point he's not able to fix the new compiler feature: > > > > https://dlang.org/changelog/2.072.0.html#deferred_alias > > > > Then let's revert this feature until he has the time to work on it. > > Well, your code involves a recursive template, and it's not clear whether > it's actually possible to be compiled. 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. > 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.

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

Seems like the base classes symtab is empty or corrupted even though it's set to BASEOKsemanticdone.

The compiler fails to resolve the recursive DynPub field in CustomControl using forward references, subsequently the CustomControl base class has Type.error and the overload check fails. Could be a problem with the change aliasSemantic code, but also the modified determineFields/Size logic. The recursion error seems to get triggered by a speculative IsExpression, rooted in instantiating Array!ItemClass in the recursive PublishedObjectArray.

Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/0aac63dc94ec9471d46e1cfc3de5c2f229db6977 fix Issue 16574 - forward reference issue with with speculative test - must not set the type to Type.terror when determineSize is run speculatively https://github.com/dlang/dmd/commit/b2691f3434ad4cbe506ff2a047aaac70c2e4ad3a Merge pull request #6262 from MartinNowak/fix16574 fix Issue 16574 - forward reference issue with with speculative test

Thanks much for this fix.

*** Issue 16696 has been marked as a duplicate of this issue. ***

Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/0aac63dc94ec9471d46e1cfc3de5c2f229db6977 fix Issue 16574 - forward reference issue with with speculative test https://github.com/dlang/dmd/commit/b2691f3434ad4cbe506ff2a047aaac70c2e4ad3a Merge pull request #6262 from MartinNowak/fix16574

Commits pushed to scope at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/0aac63dc94ec9471d46e1cfc3de5c2f229db6977 fix Issue 16574 - forward reference issue with with speculative test https://github.com/dlang/dmd/commit/b2691f3434ad4cbe506ff2a047aaac70c2e4ad3a Merge pull request #6262 from MartinNowak/fix16574

Commits pushed to newCTFE at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/0aac63dc94ec9471d46e1cfc3de5c2f229db6977 fix Issue 16574 - forward reference issue with with speculative test https://github.com/dlang/dmd/commit/b2691f3434ad4cbe506ff2a047aaac70c2e4ad3a Merge pull request #6262 from MartinNowak/fix16574