Open royjacobson opened 2 years ago
The reason we do need a different mangling is for the following case
struct S {
static void f(S);
void f(this S);
};```
I'd be inclined to mangle the presence of an explicit object parameter in <nested-name>
, like we currently do function cv-quals and ref-quals for implicit object member functions.
Maybe 'B', since 'O' is already a ref-qualifier, and 'E' might create confusion with the end marker. Or perhaps 'X'.
Or we could make the above case an ill-formed overload set and not need to mangle it at all.
Or we could make the above case an ill-formed overload set and not need to mangle it at all.
That would be my preferred solution I think. But we'd need an other round trip through wg21, and i think they might have already discussed that point (not 100% sure)
Or we could make the above case an ill-formed overload set and not need to mangle it at all.
That would be my preferred solution I think. But we'd need an other round trip through wg21, and i think they might have already discussed that point (not 100% sure)
https://isocpp.org/files/papers/P2797R0.html Alas! @jicama I'm not sure how ABI discussions usually go. I'm happy to use either B or O or whatever other scheme :)
Doesn't matter too much, but I like 'x' for the eXplicit object parameter
Is there any world in which we want an ABI tag marker to appear as part of the cv-qualifier sequence on a function? If not, B
seems fine to me. (Otherwise, how about H
(tHis
)? That seems entirely unused.)
Presumably this marker appears instead of the [\
@zygoloid I'm happy with either option but we should pick one (Otherwise i might use a vendor extension in clang until this is resolved). Maybe H
is the option with the least question so we can go with that
I think having NB3foo
as an explicit object parameter marker but N1XB3foo
as an abi tag would be confusing for human readers of manglings, even if it's unambiguous, so I think we should use H
.
@zygoloid thanks. I went with H
in clang.
Should we standardize using H then? We also need to implement this change in the demangler and we're wondering if we want to go with H
now or if we need to wait for this to be settled to something else in the official ABI?
GCC uses H since https://gcc.gnu.org/r14-7222 Would be nice if this was actually turned into the mangling ABI patch and pushed.
Hi,
Has there been a discussion about the mangling scheme for "deducing this" methods from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html? At least MSVC seem to have different mangling scheme for those new functions, but I couldn't find anything related to Itanium.