[C++20][Modules] Weird behavior on std::tuple_element & co. reexport

[DanShaders]

With the following code,

module;

#include <utility>

export module test;

export namespace exported {

using ::std::tuple_element;
using ::std::tuple_size;
using ::std::integral_constant;

}

#include <cstdint>

import test;

struct Foo {
    template<std::size_t i>
    int get() { return 0; }
};

template<>
struct exported::tuple_size<Foo> : exported::integral_constant<std::size_t, 1> {};

template<>
struct exported::tuple_element<0, Foo> { using type = int; };

void foo() {
    auto [a] = Foo{};
}

Clang produces the following diagnostic:

consumer.cpp:17:10: error: type 'Foo' decomposes into 0 elements, but 1 name was provided
   17 |     auto [a] = Foo{};
      |          ^
1 error generated.

as if it doesn't see tuple_size specialization. Note that the diagnostic goes away if I add

namespace std {

export using ::std::tuple_element;
export using ::std::tuple_size;

}

to the module file. I'm not sure if this code is actually UB-free according to standard (it's definitely not when I start touching std namespace) but the current Clang behavior is very confusing.

CE: https://godbolt.org/z/rKxYjrn11

[DanShaders]

CC @ChuanqiXu9

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Dan Klishch (DanShaders)

With the following code, ```cpp module;

#include <utility>

export module test;

export namespace exported {

using ::std::tuple_element;
using ::std::tuple_size;
using ::std::integral_constant;

}

```cpp
#include <cstdint>

import test;

struct Foo {
    template<std::size_t i>
    int get() { return 0; }
};

template<>
struct exported::tuple_size<Foo> : exported::integral_constant<std::size_t, 1> {};

template<>
struct exported::tuple_element<0, Foo> { using type = int; };

void foo() {
    auto [a] = Foo{};
}

Clang produces the following diagnostic:

consumer.cpp:17:10: error: type 'Foo' decomposes into 0 elements, but 1 name was provided
   17 |     auto [a] = Foo{};
      |          ^
1 error generated.

as if it doesn't see tuple_size specialization. Note that the diagnostic goes away if I add

namespace std {

export using ::std::tuple_element;
export using ::std::tuple_size;

}

to the module file. I'm not sure if this code is actually UB-free according to standard but the current Clang behavior is definitely very confusing.

CE: https://godbolt.org/z/rKxYjrn11

[ChuanqiXu9]

I suspect if this is true positive. Since std::tuple is not visible to consumer. But I am not sure.

BTW, from user's perspective, I suggest you to use import std; to avoid such problems.

[DanShaders]

BTW, from user's perspective, I suggest you to use import std; to avoid such problems.

I know, I wouldn't have written such a weird piece of code in the first place if I hadn't had strong reasons to do so. The idea here is to export a very small subset of std magic into the rest of the codebase (in particular, SerenityOS kernel) that cannot use std because it doesn't link to it.

I also think I know what's going on: std::tuple_size is actually std::__1::tuple_size, so when I specialize exported::tuple_size I actually specialize std::__1::tuple_size. But in the consumer code, there is nothing telling the compiler that std::__1::tuple_size and std::tuple_size are actually the same thing, so Clang ends up synthesizing a completely unrelated definition of std::tuple_size which I indeed didn't specialize.

And even if std::tuple_size was defined in std namespace, std::tuple_size doesn't name "a complete class type" at the point of auto [a] = Foo{}; (as per dcl.struct.bind) unless it is exported from the module or explicitly declared in consumer.cpp, so my code is ill-formed.