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.
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
