On 16 Jan 2019, at 18:32, Richard Smith wrote:
> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On 16 Jan 2019, at 9:13, Aaron Ballman wrote:
>>
>>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka <ahatan...@apple.com>
>>> wrote:
>>>>
>>>> Yes, the behavior of the compiler doesn’t match what’s explained
>>>> in the documentation anymore.
>>>>
>>>> Please take a look at the attached patch, which updates the
>>>> documentation.
>>>
>>> Patch mostly LGTM, but I did have one wording suggestion.
>>>
>>>> diff --git a/include/clang/Basic/AttrDocs.td
>>>> b/include/clang/Basic/AttrDocs.td
>>>> index 5773a92c9c..ca3cfcf9b2 100644
>>>> --- a/include/clang/Basic/AttrDocs.td
>>>> +++ b/include/clang/Basic/AttrDocs.td
>>>> @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation {
>>>> let Category = DocCatVariable;
>>>> let Content = [{
>>>> The ``trivial_abi`` attribute can be applied to a C++ class, struct,
>>>> or union.
>>>> -It instructs the compiler to pass and return the type using the C
>>>> ABI for the
>>>> +``trivial_abi`` has the following effects:
>>>> +
>>>> +- It instructs the compiler to pass and return the type using the C
>>>> ABI for the
>>>> underlying type when the type would otherwise be considered
>>>> non-trivial for the
>>>> purpose of calls.
>>>> -A class annotated with `trivial_abi` can have non-trivial
>>>> destructors or copy/move constructors without automatically becoming
>>>> non-trivial for the purposes of calls. For example:
>>>> +- It makes the destructor and copy and move constructors of the
>>>> class trivial
>>>> +that would otherwise be considered non-trivial under the C++ ABI
>>>> rules.
>>>
>>> How about: It makes the destructor, copy constructors, and move
>>> constructors of the class trivial even if they would otherwise be
>>> non-trivial under the C++ ABI rules.
>>
>> Let's not say that it makes them trivial, because it doesn't. It causes
>> their immediate non-triviality to be ignored for the purposes of
>> deciding
>> whether the type can be passed in registers.
>>
>
> Given the attribute now forces the type to be passed in registers, I think
> it'd be more to the point to say that it makes the triviality of those
> special members be ignored when deciding whether to pass a type with a
> subobject of this type in registers.
Wait, it forces it to be passed in registers? I thought the design
was that it didn't override the non-trivial-abi-ness of subobjects;
see all the discussion of trivially_relocatable.
John.
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
