Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hugoam opened this issue Jan 16, 2022 · 8 comments
Assignees
Labels
clang:modules C++20 modules and Clang Header Modules

Comments

@hugoam
Copy link

hugoam commented Jan 16, 2022

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
@EugeneZelenko EugeneZelenko added clang:modules C++20 modules and Clang Header Modules and removed new issue labels Jan 16, 2022
@llvmbot
Copy link
Member

llvmbot commented Jan 16, 2022

@llvm/issue-subscribers-clang-modules

@urnathan
Copy link
Contributor

urnathan commented Feb 14, 2022

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
Copy link

kamrann commented Aug 25, 2024

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
Copy link
Member

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
Copy link

kamrann commented Aug 26, 2024

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
Copy link
Member

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
Copy link

kamrann commented Aug 26, 2024

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:modules C++20 modules and Clang Header Modules
Projects
None yet
Development

No branches or pull requests

6 participants