Modules - unexpected error "definition with same mangled name as another definition" with lambdas

[hugoam]

Clang will trigger a compilation error with:

• (A) a simple module interface with a template function calling a function object passed to it
• (B) a call to that function from a module passing a lambda twice in the same enclosing scope

This will cause the following compiler error: greetings.cpp:6:6: error: definition with same mangled name '_ZW9greetingsE5greetIZW_0E4testvEUt_EvT_' as another definition

This happens only if the use in (B) is part of a module as well (it can be an implementation unit of the same module, or it can also be part of a second module test which will trigger the error as well).

This seems to be some kind of variation of the following long closed bug: https://bugs.llvm.org/show_bug.cgi?id=33924

greetings.cpp

export module greetings;
 
import <string>;
 
export template <class Func>
void greet(Func f)
{
    return f("Hello, World!");
}

test.cpp

module greetings;
// this would trigger the error as well:
// export module test;
import <iostream>;

int test()
{
    greet([](const std::string& text) { std::cout << text << '\n'; });
    greet([](const std::string& text) { std::cout << text << '\n'; });
    return 1;
}

Compilation commands:

clang++ -Wall -std=c++2a -stdlib=libc++ -fimplicit-modules -fimplicit-module-maps -fmodules --precompile -x c++-module greetings.cpp -o greetings.pcm
clang++ -Wall -std=c++2a -stdlib=libc++ -fimplicit-modules -fimplicit-module-maps -fmodule-file=greetings.pcm -c test.cpp -o test.o

Alternate command if test.cpp is meant to be part of a different module:

clang++ -Wall -std=c++2a -stdlib=libc++ -fimplicit-modules -fimplicit-module-maps -fprebuilt-module-path=. -c test.cpp -o test.o

[llvmbot]

@llvm/issue-subscribers-clang-modules

[urnathan]

It looks like the mangler's not attaching a discriminating integer to the lambdas?

http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling

<closure-type-name> ::= Ul <lambda-sig> E [ <nonnegative number> ] _

The number is omitted for the first closure type with a given <lambda-sig> in a given context; it is n-2 for the nth closure type (in [lexical order]) with that same <lambda-sig> and context.

[kamrann]

Curious, was this issue considered fixed along with #52857 and was simply forgotten to be closed, or is there a remaining issue?
It's old so I'd assume the former, however I've run into this on latest clang (clang version 20.0.0git (https://github.com/llvm/llvm-project.git b7c7dbd473c0857d0d86b228e45ce5a0a68a1a1b)).

I can try to reproduce but I suspect it's going to be awkward so wanted to check first what the known status was. Also curious if this "same mangled name" error is a genuine error that can mean something is wrong with the program source code, or is it just a way of surfacing a problem with the compiler? If the former, what would be a simple example?

[ChuanqiXu9]

Curious, was this issue considered fixed along with #52857 and was simply forgotten to be closed, or is there a remaining issue? It's old so I'd assume the former, however I've run into this on latest clang (clang version 20.0.0git (https://github.com/llvm/llvm-project.git b7c7dbd473c0857d0d86b228e45ce5a0a68a1a1b)).

I can try to reproduce but I suspect it's going to be awkward so wanted to check first what the known status was. Also curious if this "same mangled name" error is a genuine error that can mean something is wrong with the program source code, or is it just a way of surfacing a problem with the compiler? If the former, what would be a simple example?

I thought this is simply forgotten to be closed. I think a reproducer will be pretty helpful.

[kamrann]

I just spent a couple of hours trying to reduce but I'm still a long way off anything reasonable. It's happening in a very heavily nested template context, spanning module boundaries, and it's very sensitive to changes. When I tweak something, it will either disappear or, strangely, emit the same error but for some other template definition in the stack of instantiations.

Since they were always pointing at lambdas inside of function templates, my gut feeling was saying it could be related to #59513 , but then the very last change I made caused the same error to show up directly on a function template, not a lambda (though perhaps it could still be related, since there are lambdas on the instantiation stack?).

I need to put repro-ing it on hold for now. It's not an open source project, but if I was eventually able to get it down to a small source file plus a bunch of dependency BMIs would that be any use? Or do you need a full source code repro to be able to get anywhere?

[ChuanqiXu9]

I need to put repro-ing it on hold for now. It's not an open source project, but if I was eventually able to get it down to a small source file plus a bunch of dependency BMIs would that be any use? Or do you need a full source code repro to be able to get anywhere?

I need to the source code repros. The BMIs are too sensitive to be reproducer.

[kamrann]

Ok. Given how long it would take to reduce it down to something sensible I'm unsure I'll be able to justify the time, unless it becomes a more frequent problem.

Feel free to close this issue, and if at some point I have a reproducer I'll open a new one and reference this. Cheers.

[ChuanqiXu9]

Yeah, it is a known problem that it is hard to reproduce modules related bugs. Thanks for reaching out.