Bug 52702 - [C++11] std::is_trivially_destructible is missing
Summary: [C++11] std::is_trivially_destructible is missing
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: 4.8.0
Assignee: Paolo Carlini
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2012-03-24 17:14 UTC by Daniel Krügler
Modified: 2012-04-22 08:05 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-04-12 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Krügler 2012-03-24 17:14:37 UTC
gcc 4.8.0 20120318 (experimental) in C++11 mode rejects the following code:

//-----
#include <type_traits>

struct pod {};
struct non_pod { ~non_pod(); };

static_assert(std::is_trivially_destructible<pod>::value, "");
static_assert(std::is_trivially_destructible<int>::value, "");
static_assert(!std::is_trivially_destructible<non_pod>::value, "");
//-----

due to the missing definition of the is_trivially_destructible type trait.

This should not be much work, because the TR1 trait has_trivial_destructor does exist and uses the __has_trivial_destructor intrinsic and is_destructible is also provided.
Comment 1 Paolo Carlini 2012-04-12 12:22:10 UTC
Ok, thanks.
Comment 2 Paolo Carlini 2012-04-15 13:43:51 UTC
Daniel I'm adding this.

By the way, is "is_nothrow_destructible" doable just now or needs compiler support? Are you willing to give it a try, in case? (or, if necessary, I can do the compiler bits) It would complete our implementation of the is_nothrow_* set.
Comment 3 Daniel Krügler 2012-04-15 14:05:43 UTC
(In reply to comment #2)
> Daniel I'm adding this.
> 
> By the way, is "is_nothrow_destructible" doable just now or needs compiler
> support? Are you willing to give it a try, in case? (or, if necessary, I can do
> the compiler bits) It would complete our implementation of the is_nothrow_*
> set.

The reason why I did not suggested it for the moment is simply because LWG issue

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2049

is still open. Actually, the correct solution for no_throw_destructible depends on the P/R as well. Of-course one could simply start with a partial solution (e.g. handle uncontroversial types like reference types, non-function, and non-abstract types), but I'm not sure whether it is worth the effort. If you would like to have just an consistent current trait matching to the current is_destructible implementation, I can work on that. Roughly about the mid of up-coming week would seem reasonable for me to start on that.
Comment 4 Paolo Carlini 2012-04-15 14:30:19 UTC
Ah, I see, I didn't know about that DR.

Then, sure, whenever you like it would be great if you could contribute is_nothrow_destructible too: should not be much more controversial than is_destructible itself (which you contributed already and I'm going to use for is_trivially_destructible of course)

Let's keep in touch!
Comment 5 Paolo Carlini 2012-04-15 17:05:18 UTC
Maybe we can ask here Jason about std::is_trivially_copyable, which he didn't do at once with std::is_trivial (maybe the concept didn't precisely exist at the time, I don't remember).

Anyway, I see two options: either "exporting" just now from the front-end an __is_trivially_copyable (just using trivially_copyable_p); or postpone the task to when std::is_trivially_constructible and std::is_trivially_assignable will be available, in turn requiring front-end support, but then useful for all the missing std::is_trivial* things, if I understand correctly.

The former could make sense per se, could also be immediately exploited to implement std::is_trivially_default_constructible. At some point, anyway, we'll have to tackle std::is_trivially_constructible and std::is_trivially_assignable (the former, in particular, with its variadic parameter, seems non-trivial to me)
Comment 6 Paolo Carlini 2012-04-15 17:48:21 UTC
Scratch the std::is_trivially_default_constructible bit, sorry.
Comment 7 paolo@gcc.gnu.org 2012-04-15 23:35:33 UTC
Author: paolo
Date: Sun Apr 15 23:35:27 2012
New Revision: 186474

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186474
Log:
2012-04-15  Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/52702
	* include/std/type_traits (is_trivially_destructible): Add.
	(has_trivial_destructor): Remove.
	* testsuite/util/testsuite_common_types.h: Adjust.
	* testsuite/20_util/tuple/requirements/dr801.cc: Likewise.
	* testsuite/20_util/pair/requirements/dr801.cc: Likewise.
	* testsuite/20_util/is_trivially_destructible/value.cc: New.
	* testsuite/20_util/is_trivially_destructible/requirements/
	typedefs.cc: Likewise.
	* testsuite/20_util/is_trivially_destructible/requirements/
	explicit_instantiation.cc: Likewise.
	* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
	Adjust dg-error line numbers.
	* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
	Likewise.
	* testsuite/20_util/declval/requirements/1_neg.cc: Likewise.

Added:
    trunk/libstdc++-v3/testsuite/20_util/is_trivially_destructible/
    trunk/libstdc++-v3/testsuite/20_util/is_trivially_destructible/requirements/
    trunk/libstdc++-v3/testsuite/20_util/is_trivially_destructible/requirements/explicit_instantiation.cc
    trunk/libstdc++-v3/testsuite/20_util/is_trivially_destructible/requirements/typedefs.cc
    trunk/libstdc++-v3/testsuite/20_util/is_trivially_destructible/value.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/type_traits
    trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/pair/requirements/dr801.cc
    trunk/libstdc++-v3/testsuite/20_util/tuple/requirements/dr801.cc
    trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h
Comment 8 Paolo Carlini 2012-04-22 08:05:18 UTC
Done.