Would it be better if we disallowed trivial_abi if the class’ copy and move
destructors were all deleted (and revert r350920)? I think that would make it
easier to reason about when you are allowed to use trivial_abi and what effect
the attribute has (which is to override the trivialness for the purpose of
calls).
Sorry for my late reply. It took a while to understand that the patch I
committed might not be the right way to fix the problem.
> On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits
> <cfe-commits@lists.llvm.org> wrote:
>
> On 16 Jan 2019, at 20:03, Richard Smith wrote:
>
>> On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> 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.
>>>
>>
>> The attribute is ill-formed if applied to a class that has a subobject that
>> can't be passed in registers (or that has a vptr). And then as a weird
>> special case we don't instantiate the attribute when instantiating a class
>> if it would be ill-formed (well, we instantiate it and then remove it
>> again, but the effect is the same).
>>
>> The commit at the start of this email chain switches us from the "just
>> override the trivialness for the purposes of the ABI" model to /also/
>> forcing the type to be passed in registers (the type would otherwise not be
>> passed in registers in some corner cases, such as if all its copy/move
>> special members are deleted).
>
> I see. Alright, I accept your wording, then.
>
> John.
> _______________________________________________
> cfe-commits mailing list
> cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
