[Bug libstdc++/51365] New: cannot use final empty class in std::tuple

[Bug libstdc++/51365] New: cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

             Bug #: 51365
           Summary: cannot use final empty class in std::tuple
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: redi@gcc.gnu.org


#include <tuple>
struct F final { };
std::tuple<F> t;

This should work. I don't know how to make it work without a compiler-assisted
is_final trait.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011-11-30
         AssignedTo|unassigned at gcc dot       |redi at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 19:08:57 UTC ---
I'll have a go at implementing __is_final, using Paolo's work for PR 26099 as a
starting point.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-30 19:22:32 UTC ---
Yes, should be pretty trivial given the infrastructure already in place. In
semantics should be just matter of calling CLASS_TYPE_P && CLASSTYPE_FINAL

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:06:25 UTC ---
Created attachment 25961
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25961
front end patch (missing docs and tests)

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:07:00 UTC ---
Created attachment 25962
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25962
library patch (missing tests)

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 21:19:28 UTC ---
Thanks for the pointer, the hardest part was naming the new intrinsic ;)

We can't have the front-end define __is_final() as an intrinsic and also define
std::__is_final as a class template, so the patches above define
__is_final_class() and std::__is_final<>

It might be better for the front end to define __is_final() then use that
directly in the library and not provide a type trait unless std::is_final gets
added to the library by a DR.

i.e. in <tuple>

template<typename _Tp>
  using __empty_base 
    = typename conditional<__is_final(_Tp), false_type, is_empty<_Tp>>::type;

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-30 23:35:00 UTC ---
Created attachment 25963
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25963
fix other parts of library

here's a proof of concept patch showing how to fix existing code that inherits
from allocators so that it is ABI-compatible for non-final allocators and also
supports final allocators (by inheriting from a wrapper class instead). 
Something like this needs to be done for the containers so they stay backwards
compatible but also work with final types.

(I decided to rename the intrinsic to __is_final and that's what this patch
uses)

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-01 01:07:27 UTC ---
Here's another testcase:

#include <future>
#include <memory>

template<typename T>
struct final_allocator final : std::allocator<T>
{
  final_allocator() = default;

  template<typename U>
    final_allocator(const final_allocator<U>&) { }

  template<typename U>
    struct rebind { typedef final_allocator<U> other; };
};

final_allocator<int> a;

std::promise<int> p(std::allocator_arg, a);

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-03 12:06:08 UTC ---
patch implementing __is_final submitted for approval:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00231.html

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #9 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-11 12:12:29 UTC ---
Hello,

the recent discussion "Structure alignment changes when a constructor or
destructor is added" on gcc-help made me wonder whether it would make sense to
not only derive for empty classes, but actually derive by default and use
members only when necessary (builtin types, final classes). The advantage would
be that derivation allows for a slightly more compact representation in some
cases with the g++ ABI. I really haven't thought much about the consequences.

Sorry for hijacking this bug with this wild idea, but in case it makes sense it
might change slightly the way you want to fix it.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-11 13:39:20 UTC ---
I haven't really thought about it either, but one advantage of depending on
is_empty is that it prevents using the EBO for polymorphic classes, where
derivation could have undesirable effects.  That *shouldn't* be a problem as
long as user-defined types don't have virtual functions using reserved names
such as _M_get.

Another problem could be user-defined types with a virtual base, if the tuple
node type (which would be the most-derived type) doesn't know how to construct
the virtual base.

struct A { A(int) { } };

struct B : virtual A { B() : A(1) { } };

std::tuple<B> t;

If tuple derived from B it couldn't construct the A subobject correctly.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #11 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-11 13:51:20 UTC ---
(In reply to comment #10)
> I haven't really thought about it either, but one advantage of depending on
> is_empty is that it prevents using the EBO for polymorphic classes, where
> derivation could have undesirable effects.

Ah, right, the set of types that can safely be derived from is rather
restricted: non-builtin, non-final, non-virtual (and possibly more
constraints). And to benefit from additional packing: non-C++03-POD. Probably
not worth the trouble...

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-15 10:02:50 UTC ---
Author: redi
Date: Thu Dec 15 10:02:45 2011
New Revision: 182360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182360
Log:
c-family:
    PR libstdc++/51365
    * c-common.c (RID_IS_FINAL): Add.
    * c-common.h (RID_IS_FINAL): Add.
cp:
    PR libstdc++/51365
    * cp-tree.h (CPTK_IS_FINAL): Add.
    * parser.c (cp_parser_translation_unit): Handle RID_IS_FINAL.
    (cp_parser_primary_expression, cp_parser_trait_expr): Likewise.
    * semantics.c (trait_expr_value, finish_trait_expr): Handle
    CPTK_IS_FINAL.
    * cxx-pretty-print.c (pp_cxx_trait_expression): Likewise.
testsuite:
    PR libstdc++/51365
    * g++.dg/ext/is_final.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/ext/is_final.C
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c-family/c-common.h
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/cxx-pretty-print.c
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-15 10:06:19 UTC ---
front end changes done, I'll work on the library parts this weekend

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-20 09:09:56 UTC ---
Author: redi
Date: Tue Dec 20 09:09:50 2011
New Revision: 182523

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182523
Log:
    PR libstdc++/51365
    * include/std/tuple (_Tuple_impl): Check __is_final as well as
    is_empty.
    * testsuite/20_util/tuple/51365.cc: New.

Added:
    trunk/libstdc++-v3/testsuite/20_util/tuple/51365.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/tuple

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-04 13:53:44 UTC ---
Given the number of other PRs I'm working on and that we're in stage4 I'm not
going to handle 'final' allocators for 4.7 so I'll come back to it for 4.8
(when I also plan to update all the containers to use C++11 allocators)

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:44:18 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.9.0

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-04-28 11:40:24 UTC ---
shared_ptr fixed to handle final allocators by:

Author: redi
Date: Sun Apr 28 11:38:21 2013
New Revision: 198367

URL: http://gcc.gnu.org/viewcvs?rev=198367&root=gcc&view=rev
Log:
    PR libstdc++/51365
    * include/bits/shared_ptr_base (_Sp_ebo_helper): Helper class to
    implement EBO safely.
    (_Sp_counted_base::_M_get_deleter): Add noexcept.
    (_Sp_counter_ptr): Use noexcept instead of comments.
    (_Sp_counted_deleter): Likewise. Use _Sp_ebo_helper.
    (_Sp_counted_ptr_inplace): Likewise.
    * testsuite/20_util/shared_ptr/cons/51365.cc: New.
    * testsuite/20_util/shared_ptr/cons/52924.cc: Add rebind member to
    custom allocator and test construction with custom allocator.
    * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-error
    line number.

Added:
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/51365.cc
      - copied, changed from r198365,
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/52924.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/shared_ptr_base.h
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
    trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/52924.cc

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.9.1                       |4.7.0

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm closing this as fixed, I've created Bug 60921 to deal with the remaining
final allocator issues.