Open Quuxplusone opened 3 years ago
Bugzilla Link | PR50001 |
Status | NEW |
Importance | P normal |
Reported by | Hoch Hochkeppel (mhochk@microsoft.com) |
Reported on | 2021-04-16 11:07:44 -0700 |
Last modified on | 2021-04-20 15:40:36 -0700 |
Version | unspecified |
Hardware | PC Windows NT |
CC | llvm-bugs@lists.llvm.org, mclow.lists@gmail.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
If we were to do something like this, I suspect that we'd have to do it in a LOT of places; not just in string_view.
Why is clang-cl doing this?
I don't have a complete understanding of *why* clang-cl is doing this, but have
been told and pointed at a Microsoft internal bug #409326 that says this is a
flaw in the name mangling logic and does not work with the "identity_t trick"
(which is a shorthand for this syntax being used). This bug is unfortunately
from before such issues were hosted in a public location so I can't share a
link to it, but I can point at where this same work-around is being applied in
the Microsoft MSVC/STL implementation of string_view here: (Search for 409326)
https://github.com/microsoft/STL/blob/main/stl/inc/xstring
In my search through the libcxx code for a similar pattern the only place I see
overloaded functions relying on 'typename identity/common_type<>::type' to
distinguish them is in the string_view comparison operators (though admittedly
more than just the == operator). I may have missed some instance somewhere as I
only read a subset of the code based on search results, but the fact that the
STL implementation only references this bug in the string_view operators and
the fact that the underlying name mangling bug is 4+ years old without this
issue having come up publicly before encourages me that this is indeed the only
location being impacted.
When I look at that file you reference, I see that "trick" being done 13 times:
twice on operator==
twice on operator!=
twice on operator<
twice on operator<=
twice on operator>
twice on operator>=
once on operator<=>
Yes, sorry I was not explicit about that. When I said the only place this applied was the "string_view comparison operators (though admittedly more than just the == operator)" I meant all the comparison operators for string_view, not just the equality operator.