[C++20][Modules] Variable template in instantiation chain attached to wrong module

[davidstone]

Given the following translation units:

export module a;

template<typename>
constexpr auto impl = true;

export template<typename T>
void a() {
}

export template<typename T> requires impl<T>
void a() {
}

export module b;

import a;

static void b() {
	a<void>();
}

export module c;

import a;

static void c() {
	a<void>();
}

import a;
import b;
import c;

static void d() {
	a<void>();
}

clang incorrectly errors with

In file included from /app/d.cpp:1:
a.cpp:4:16: error: declaration 'impl<void>' attached to named module 'b' can't be attached to other modules
    4 | constexpr auto impl = true;
      |                ^
a.cpp:4:16: note: also found
1 error generated.

See it live: https://godbolt.org/z/fKEvse3PK

This occurs even if impl is declared static, but does not seem to occur if impl is declared in the unnamed namespace. That workaround does not work for me, because this was reduced from a bug where clang complained about a variable template specialization of a variable template exported in a different module.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: David Stone (davidstone)

Given the following translation units:

export module a;

template<typename>
constexpr auto impl = true;

export template<typename T>
void a() {
}

export template<typename T> requires impl<T>
void a() {
}

export module b;

import a;

static void b() {
	a<void>();
}

export module c;

import a;

static void c() {
	a<void>();
}

import a;
import b;
import c;

static void d() {
	a<void>();
}

clang incorrectly errors with

In file included from /app/d.cpp:1:
a.cpp:4:16: error: declaration 'impl<void>' attached to named module 'b' can't be attached to other modules
    4 | constexpr auto impl = true;
      |                ^
a.cpp:4:16: note: also found
1 error generated.

See it live: https://godbolt.org/z/fKEvse3PK

This occurs even if impl is declared static, but does not seem to occur if impl is declared in the unnamed namespace. That workaround does not work for me, because this was reduced from a bug where clang complained about a variable template specialization of a variable template exported in a different module.