Clang doesn't add thiscall calling convention to mangled template function names

[TheComputerGuy96]

Godbolt example: https://godbolt.org/z/WjG7sabd5

Real-world example: https://github.com/CookiePLMonster/SilentPatch/blob/50c3a47cd3c0c366c416dbec70151152e2ea80dd/SilentPatchSA/SilentPatchSA.cpp#L344

This (mis)behavior notably causes variable conflicts with two different variables (I can workaround this by using a more generic template and then doing a cast to the right type but that isn't the best solution)

[Alcaro]

The issue reproduces only under -target i386-pc-windows-gnu, everything's fine under -target i386-pc-windows-msvc.

Reduced a bit further, no templates needed:

using cdecl_fp = void(*)(int, int, int);
using thiscall_fp = void(__thiscall*)(int, int, int);
void call(cdecl_fp fp) { fp(1, 2, 3); }
void call(thiscall_fp fp) { fp(1, 2, 3); }

<source>:4:6: error: definition with same mangled name '_Z4callPFviiiE' as another definition
    4 | void call(thiscall_fp fp) { fp(1, 2, 3); }
      |      ^
<source>:3:6: note: previous definition is here
    3 | void call(cdecl_fp fp) { fp(1, 2, 3); }
      |      ^
1 error generated.

https://godbolt.org/z/6abEzhzca

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Echo J. (TheComputerGuy96)

Godbolt example: https://godbolt.org/z/WjG7sabd5

Real-world example: https://github.com/CookiePLMonster/SilentPatch/blob/50c3a47cd3c0c366c416dbec70151152e2ea80dd/SilentPatchSA/SilentPatchSA.cpp#L344

This (mis)behavior notably causes variable conflicts with two different variables (I can workaround this by using a more generic template and then doing a cast to the right type but that isn't the best solution)

[shafik]

CC @AaronBallman @rnk

[shafik]

Maybe related: #39454

[rnk]

cc @mstorsjo

GCC's behavior isn't totally consistent here. You can play around with member pointer types and get it to emit an error in this case, where it leaves out U8thiscall when it is implicit, but if you add an explicit __cdecl, you get two symbols with explicit conventions in them.

I think if we wanted to match this behavior, we'd need to think about mangling type sugar, which we normally drop during canonicalization, and instead go looking for things like the AttributedType type sugar node to figure out if convention was explicitly written or implicitly added by combining a function type with a member type (Foo::T).

[shafik]

CC @mizvekov