[Issue 23722] Lambdas are mangled incorrectly when using multiple compilation units, resulting in incorrect code

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Nov 20 12:03:34 UTC 2024


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

ilya.yanok at gmail.com changed:

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

--- Comment #4 from ilya.yanok at gmail.com ---
The provided example is a bit confusing since it triggers two independent bugs,
I believe :)

First bug is the one that's fixed by @dkorpel's PR: it's not about mangling
actually, but rather about assigning names to lambdas and friends. The code
simply uses the respective symtab size as a suffix, but in different
compilation units we may check things in different order, resulting in
different suffixes.

I have another example of this:

$ cat mod.d
import lib;
bool f() {
    return b;
}

$ cat lib.d
auto f(string s, alias g)() {
    return true;
}

alias a = f!("a", output => output);
alias b = f!("b", output => true);

$ nm lib.o | ddemangle
0000000000000010 s EH_frame0
0000000000000000 S lib.__ModuleInfo
0000000000000078 S pure nothrow @nogc @safe bool lib.f!("a", lib.__lambda5).f()
0000000000000088 S pure nothrow @nogc @safe bool lib.f!("b", lib.__lambda6).f()
0000000000000028 S _lib.f!("a", (output) => output).f.eh
0000000000000050 S _lib.f!("b", (output) => true).f.eh

$ nm mod.o | ddemangle
0000000000000010 s EH_frame0
                 U pure nothrow @nogc @safe bool lib.f!("b", lib.__lambda5).f()
0000000000000000 S mod.__ModuleInfo
0000000000000050 S bool mod.f()
0000000000000028 S _mod.f.eh

Note that a wrong lambda is referenced. @dkorpel's PR does indeed fix this and
I believe it should be merged ASAP.

On top of that, the example from this bug hits another issue: the code for
`A.y` is not generated at all, if the files are compiled separately.

I don't quite understand the latter issue yet. Are aliases supposed to be lazy?
Meaning the code is only generated once an alias is used? There is a problem
then:   if an alias definition needs to generate some code, at the use site we
generate a reference to a symbol that might be not generated at all.

I think we could either codegen aliases/enums eagerly, or codegen using weak
symbols at use sites, like we do for templates.

--


More information about the Digitalmars-d-bugs mailing list