Thread overview
[Issue 24085] Separate Compilation Bugs
Aug 16, 2023
RazvanN
August 16, 2023
https://issues.dlang.org/show_bug.cgi?id=24085

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
Note that if you delete the useless imports of bar in frop and frop in bar, you get the same result in both signed and unsigned versions.

This looks like the unsigned case somehow manages to instantiate all of the methods of FooImpl. I don't see how this happens: maybe the  compiler generates some code or tries semantic on some construction.

--
October 18
https://issues.dlang.org/show_bug.cgi?id=24085

ilya.yanok@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilya.yanok@gmail.com

--- Comment #2 from ilya.yanok@gmail.com ---
I think I'm also affected by the same bug (also reproducible with LDC), but I think my minimal example uses even less features. There is also a cyclic dependency and an overloaded operator though.

That's what dustmite produced (doesn't make sense, because of infinite recursion, but still symbols should be there, I think):

// option.d
import util;
struct Option(T) {
        int opCmp()(const(Option) rhs) const {
            return this.opCmp(rhs);
        }
}
Option!string f;

// util.d
import option;
Option!string x;

// dmd -c option.d
// dmd -c util.d
// nm option.o util.o | ddemangle | grep 'opCmp!'
// Neither of .o files have an implementation for this symbol


It is possible to make the actual implementation more reasonable, while still having this issue.

--
October 23
https://issues.dlang.org/show_bug.cgi?id=24085

--- Comment #3 from ilya.yanok@gmail.com ---
UPD: even though my issue looked similar, it turned out to be unrelated: I managed to fix my issue, but the issue described in the bug is still there.

--