On 31 Jan 2019, at 16:57, Akira Hatanaka wrote:
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.
I'd be fine with that. If nothing else, we can generalize it later if
we decide that's an important use-case.
John.
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
