Skip to content

[clang++] Implicit template instantiations in modules cause errors in other modules #125521

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
BernardoGomesNegri opened this issue Feb 3, 2025 · 4 comments
Assignees
Labels
clang:modules C++20 modules and Clang Header Modules

Comments

@BernardoGomesNegri
Copy link

BernardoGomesNegri commented Feb 3, 2025

If module A instantiates a template Class<T>, any module that imports module A and also tries to instantiate Class<T> (with the same T) will get an error:

/home/modBug/reproducer/src/hello.h:8:38: error: declaration 'get' attached to named module 'Mod2' can't be attached to other modules
    8 |     template <typename V> friend int get() noexcept;
      |                                      ^
/home/modBug/reproducer/src/hello.h:3:27: note: also found
    3 | template <typename V> int get() noexcept {return 0;};
      |                           ^

See this reproducer or https://godbolt.org/z/d7YW7TM4a where instantiating List<int> in Mod2 causes any module that also imports Mod2 to fail to instantiate List<int>.
I think this is a bug because the global module fragment is not supposed to be exported.
Reproducer:

hello.h:

template <typename V> int get() noexcept {return 0;};

template <typename T>
class List
{
    template <typename V> friend int get() noexcept;
};

mod.cpp:

module;
#include "hello.h"
export module Mod;
import Mod2;
export const char *modFn() {
    List<int> a;
    List<double> b;
    return modFn2();
}

mod2.cpp:

module;
#include "hello.h"
export module Mod2;
export const char *modFn2() {
    List<int> a;
    return "hello";
}

main.cpp:

#include <iostream>

import Mod;

int main(int argc, char** argv) {
    std::cout << modFn() << '\n';
}
@llvmbot llvmbot added the clang Clang issues not falling into any other category label Feb 3, 2025
@EugeneZelenko EugeneZelenko added clang:modules C++20 modules and Clang Header Modules and removed clang Clang issues not falling into any other category labels Feb 3, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 3, 2025

@llvm/issue-subscribers-clang-modules

Author: None (BernardoGomesNegri)

If module A instantiates a template Class\<T\>, any module that imports module A and also tries to instantiate Class\<T\> (with the same T) will get an error: ``` /home/modBug/reproducer/src/hello.h:8:38: error: declaration 'get' attached to named module 'Mod2' can't be attached to other modules 8 | template <typename V> friend int get() noexcept; | ^ /home/modBug/reproducer/src/hello.h:3:27: note: also found 3 | template <typename V> int get() noexcept {return 0;}; | ^ ``` See [this reproducer](https://github.com/user-attachments/files/18644458/reproducer.zip) or https://godbolt.org/z/d7YW7TM4a where instantiating List\<int\> in Mod2 causes any module that also imports Mod2 to fail to instantiate List\<int\>. I think this is a bug because the global module fragment is not supposed to be exported.

@BernardoGomesNegri
Copy link
Author

Might be related to (or a duplicate of) #119947 but I do not know enough to tell.

@ChuanqiXu9
Copy link
Member

/cherry-pick c5a9a72

@llvmbot
Copy link
Member

llvmbot commented Feb 5, 2025

/pull-request #125809

github-actions bot pushed a commit to arm/arm-toolchain that referenced this issue Feb 5, 2025
…tions between modules incorrectly

Close llvm/llvm-project#125521

We shouldn't use the ownership information for friend declarations to do
anything.
@tstellar tstellar moved this from Needs Triage to Done in LLVM Release Status Feb 8, 2025
swift-ci pushed a commit to swiftlang/llvm-project that referenced this issue Feb 10, 2025
…en modules incorrectly

Close llvm#125521

We shouldn't use the ownership information for friend declarations to do
anything.

(cherry picked from commit c5a9a72)
github-actions bot pushed a commit to arm/arm-toolchain that referenced this issue Feb 10, 2025
…tions between modules incorrectly

Close llvm/llvm-project#125521

We shouldn't use the ownership information for friend declarations to do
anything.

(cherry picked from commit c5a9a72)
Icohedron pushed a commit to Icohedron/llvm-project that referenced this issue Feb 11, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…en modules incorrectly

Close llvm#125521

We shouldn't use the ownership information for friend declarations to do
anything.
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
Development

No branches or pull requests

4 participants