> On Jun 2, 2016, at 4:22 PM, John McCall <[email protected]> wrote:
>> On Jun 2, 2016, at 3:01 PM, Richard Smith <[email protected]
>> <mailto:[email protected]>> wrote:
>> Thank you for writing this up!
>>
>> If a type is not part of the regular mangling, and it contains an ABI tag in
>> its mangling but not as part of its type (for instance, a dependent
>> expression in a template argument references an entity with an ABI tag),
>> does that appear in the resulting mangling?
>>
>> (That is, is an implementation required to effectively mangle the return
>> type and throw it away, or is some walk over the top-level type required
>> instead?)
>>
>
> Do templates have ABI tags, or are the tags only properties of template
> specializations? How does that play into mangling and/or substitutability?
To answer my own question here, tags must be associated with the class
template, not with its specific specializations, because a template
specialization can be used as an incomplete type without requiring explicit
specializations etc. to have already been declared. So you cannot e.g. tag a
specific explicit specialization (e.g. std::vector<bool>) or template "pattern"
as having been ABI-updated; you have to tag the entire template. Uses of the
template as e.g. a template template argument must include the tag as well.
> I assume ABI tags can apply to unions as well. (The standard's definition of
> "compound type" distinguishes classes and unions.)
>
> It's probably worth spelling out that tags do not apply to enumerators.
>
> Are ABI tags mangled in the <prefix>, or just on the entity <name>? What
> happens if the same tag is applied to multiple places in the lexical
> hierarchy, e.g. to both a class and one of its member functions?
>
> I guess an inline friend function definition doesn't implicitly use the tags
> of its defining class, but presumably has them anyway because of their
> presence in the function signature.
>
> Can you clarify which things in the Clang description are no longer correct?
> I assume that a type used in the name of a conversion function should be
> mangled with its ABI tag. Also, I don't see anything in your proposed
> wording that talks about not mangling ABI tags on an entity that appear in
> its type.
I wonder if we should include a rationale for this feature. At a first glance,
it's tempting to say that it's largely redundant with inline namespaces. The
main differences are:
- You can pile up multiple tags on an entity. It's possible to stack inline
namespaces, but that seems unappealing, and it wouldn't be as easy for other
language features to help with the tagging problem.
Piling tags on an entity is useful when you've made several orthogonal
revisions to it, e.g. when a member variable of a struct has a type that
changes ABI. Now, that's a case that doesn't propagate out implicitly because
of the incomplete-type problem, but it can still propagate out explicitly, e.g.
using a compiler feature that warns about "public" types that don't declare all
the tags of their member variables. You'd probably want some way to explicitly
propagate the tags of a declaration, e.g. __attribute__((abi_tag(std::string)))
to give an entity all the tags that std::string has.
- You can tag a member function, member type, or static member variable
independently of the enclosing type.
- Tags are mangled even for component types that aren't mangled, like the
types of variables and the return types of non-template functions.
John.
> John.
>
>
>
>
>
>>
>> On 2 Jun 2016 2:33 p.m., "Jason Merrill" <[email protected]
>> <mailto:[email protected]>> wrote:
>> I've finally written up a specification for abi_tag mangling for the ABI
>> standard:
>>
>> https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412
>>
>> <https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412>
>>
>> Note that some of the subtleties with local scopes described in the clang
>> ABI tag documentation (http://clang.llvm.org/docs/ItaniumMangleAbiTags.html
>> <http://clang.llvm.org/docs/ItaniumMangleAbiTags.html>) are due to bugs in
>> GCC 5 that are fixed in GCC 6.
>>
>> Jason
>> _______________________________________________
>> cxx-abi-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>> <http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev>
>> _______________________________________________
>> cxx-abi-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
> _______________________________________________
> cxx-abi-dev mailing list
> [email protected]
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
