Mangling of structured bindings

[jakubjelinek]

Consider

template <typename T>
int
foo ()
{
  static int a = 1, b = 2, c = 3;
  int d = a++ + b++ + c++;
  {
    static int a = 1, b = 2, c = 3;
    d += a++ + b++ + c++;
    {
      static auto [a, b1, b2, b3, c] = T {};
      return a++ + c++ + b2++ + d;
    }
  }
}

struct A { int a, b, c, d, e; };

void
bar ()
{
  foo <A> ();
}

namespace std {
  template<typename T> struct tuple_size;
  template<int, typename> struct tuple_element;
}

struct B {
  int a[5];
  template <int I> int &get () { return a[I]; }
};
         
template<> struct std::tuple_size<B> { static const int value = 5; };
template<int I> struct std::tuple_element<I,B> { using type = int; };

void
baz ()
{
  foo <B> ();
}

E.g. in foo <B>, both clang++ and g++ properly mangle the outermost a, b, c as

_ZZ3fooI1BEivE1{a,b,c}

the one in the next scope
_ZZ3fooI1BEivE1{a,b,c}_0

but then g++ mangles the individual vars in the tuple structured bindings
_ZZ3fooI1BEivE{1a_1,2b1,2b2,2b3,1c_1}

but clang++ mangles those instead
_ZZ3fooI1BEivE{1a.1,2b1,2b2,2b3,1c.1}

I think g++ is right and clang++ is wrong.

Another question is how to mangle structured binding packs.
I've filed itanium-cxx-abi/cxx-abi#200 but nothing happened there.
Testcase would be pretty similar,

template <typename T>
int
foo ()
{
  static int a = 1, b = 2, c = 3;
  int d = a++ + b++ + c++;
  {
    static int a = 1, b = 2, c = 3;
    d += a++ + b++ + c++;
    {
      static auto [a, ...b, c] = T {};
      return a++ + c++ + b...[0]++ + d;
    }
  }
}

struct A { int a, b, c, d, e; };

void
bar ()
{
  foo <A> ();
}

namespace std {
  template<typename T> struct tuple_size;
  template<int, typename> struct tuple_element;
}

struct B {
  int a[5];
  template <int I> int &get () { return a[I]; }
};
         
template<> struct std::tuple_size<B> { static const int value = 5; };
template<int I> struct std::tuple_element<I,B> { using type = int; };

void
baz ()
{
  foo <B> ();
}

One question is whether to somehow show in the whole structured binding mangling that there is a pack in it and where (so one could demangle it as foo<B>()::[a, ...b, c] instead of just foo<B>()::[a, b, c]
And another one what mangling to use for the elements of the structured binding pack.
One possibility is just pretend it is sizeof...(pack) separate instantiations of the local variable (i.e. use b_1, b_2, b_3 in the testcase because b_0 and b_1 were previously used already), or do something else?

@ricejasonf @AaronBallman @cor3ntin

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Jakub Jelínek (jakubjelinek)

Consider ```c template <typename T> int foo () { static int a = 1, b = 2, c = 3; int d = a++ + b++ + c++; { static int a = 1, b = 2, c = 3; d += a++ + b++ + c++; { static auto [a, b1, b2, b3, c] = T {}; return a++ + c++ + b2++ + d; } } }

struct A { int a, b, c, d, e; };

void
bar ()
{
foo <A> ();
}

namespace std {
template<typename T> struct tuple_size;
template<int, typename> struct tuple_element;
}

struct B {
int a[5];
template <int I> int &get () { return a[I]; }
};

template<> struct std::tuple_size<B> { static const int value = 5; };
template<int I> struct std::tuple_element<I,B> { using type = int; };

void
baz ()
{
foo <B> ();
}

E.g. in `foo <B>`, both clang++ and g++ properly mangle the outermost a, b, c as
_ZZ3fooI1BEivE1{a,b,c}
the one in the next scope
_ZZ3fooI1BEivE1{a,b,c}_0
but then g++ mangles the individual vars in the tuple structured bindings
_ZZ3fooI1BEivE{1a_1,2b1,2b2,2b3,1c_1}
but clang++ mangles those instead
_ZZ3fooI1BEivE{1a.1,2b1,2b2,2b3,1c.1}
I think g++ is right and clang++ is wrong.

Another question is how to mangle structured binding packs.
I've filed https://github.com/itanium-cxx-abi/cxx-abi/issues/200 but nothing happened there.
Testcase would be pretty similar,
```c
template <typename T>
int
foo ()
{
  static int a = 1, b = 2, c = 3;
  int d = a++ + b++ + c++;
  {
    static int a = 1, b = 2, c = 3;
    d += a++ + b++ + c++;
    {
      static auto [a, ...b, c] = T {};
      return a++ + c++ + b...[0]++ + d;
    }
  }
}

struct A { int a, b, c, d, e; };

void
bar ()
{
  foo <A> ();
}

namespace std {
  template<typename T> struct tuple_size;
  template<int, typename> struct tuple_element;
}

struct B {
  int a[5];
  template <int I> int &get () { return a[I]; }
};
         
template<> struct std::tuple_size<B> { static const int value = 5; };
template<int I> struct std::tuple_element<I,B> { using type = int; };

void
baz ()
{
  foo <B> ();
}

One question is whether to somehow show in the whole structured binding mangling that there is a pack in it and where (so one could demangle it as foo<B>()::[a, ...b, c] instead of just foo<B>()::[a, b, c]
And another one what mangling to use for the elements of the structured binding pack.
One possibility is just pretend it is sizeof...(pack) separate instantiations of the local variable (i.e. use b_1, b_2, b_3 in the testcase because b_0 and b_1 were previously used already), or do something else?

@ricejasonf @AaronBallman @cor3ntin

[shafik]

I think gcc is correct here, I don't see why we are doing this but maybe I am missing something.

CC @zygoloid

[ricejasonf]

I don't know how pedantically we follow the Itanium ABI for this. It states, for local names in the same function but in different scopes, use a <discriminator> which is what GCC is doing. Clang is using the implementation private . suffix. I think the use of <discriminator> does make sense if we that different scopes wording was not there.

[zygoloid]

For the first issue, I think we're just forgetting to assign mangling numbers for the individual variables created for a tuple-like structured binding declaration during template instantiation -- we number them the same as GCC in non-template contexts.

For the second issue, I suppose we really have two choices: number them within the pack, or number them as if they were locals with the same name in different scopes. The latter option (use b_1, b_2, b_3 because b and b_0 were already used) seems fine to me, doesn't require inventing any new mangling scheme, and seems likely that it's what would fall out from implementations reasonably naturally (once we start assigning mangling numbers during instantiation...).

There's a related case reachable via P2169's placeholders with no name:

void f() {
  static auto [_, _, _, a] = std::tuple<int, int, int>(0, 0, 0);
}

Here again we have multiple variables for bindings with the same name in the same scope. Clang and GCC both produce bogus redefinition errors for those individual variables in this case; GCC also crashes. Presumably here again we should use discriminator numbering to distinguish the _ variables (though since they can't be referenced if there's more than one of them, this mostly only matters to establish the numbering of later variables named _ and guard variables).

So for both the pack case and the _ case, I think the right answer is to ignore the "different scopes" part of the ABI, which I think was only there to help readers understand why it's relevant and wasn't really intended to restrict the rule in the case that the language later changed to allow multiple declarations of the same variable name in the same scope!

[jakubjelinek]

There's a related case reachable via P2169's placeholders with no name:

void f() {
static auto [_, _, _, a] = std::tuple<int, int, int>(0, 0, 0);
}

Here again we have multiple variables for bindings with the same name in the same scope. Clang and GCC both produce bogus redefinition errors for those individual variables in this case; GCC also crashes.

I've fixed the crash (it was related to constexpr structured binding support, 16 only), but I'm not convinced the above is valid.
https://eel.is/c++draft/dcl.struct.bind#7 says that in the tuple case it introduces
static U0 _ = ...; static U1 _ = ...; static U2 _ = ...; static U3 a = ...;
variables and https://eel.is/c++draft/basic.scope.scope#5 says that the 3 _ vars aren't name-independent in that case, they aren't automatic variables, structured binding with no storage class specifier, etc.
So, IMHO it is correct when both compilers reject that (and accept without static).

[zygoloid]

https://eel.is/c++draft/dcl.struct.bind#7 says that in the tuple case it introduces static U0 _ = ...; static U1 _ = ...; static U2 _ = ...; static U3 a = ...; variables

To my reading, it says that it introduces variables with unique names ri, not the names of the bindings. And static U0 r0 = ...; static U1 r1 = ...; ... is fine.

[jakubjelinek]

Even if so there is https://wg21.link/cwg2764 which added that "with no storage class specifier".