This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] add __is_final trait to fix libstdc++/51365


This implements a new C++ trait, __is_final, to query the 'final'
specifier that 4.7 supports. The trait is needed for the library so we
can detect when it's not possible to derive from a type in order to
exploit the empty base-class optimisation.  This affects all
containers, std::shared_ptr, std::future, std::tuple and anywhere else
that tries to use the EBO.  It's not a C++11-only problem because we
support __final in c++98 mode.  See PR libstdc++/51365 for examples of
programs using final classes that cause problems in libstdc++ and for
patches to the library that use this trait to solve the problems.

I originally thought about naming this __is_final_class, which would
allow a possible __is_final_function in future, but I think
__is_final(type) is pretty clear.  There is a proposal to add
__is_final to Clang with the same spelling and semantics.

Tested x86_64-linux, ok for trunk?

c-family/ChangeLog:

        * c-common.c (RID_IS_FINAL): Add.
        * c-common.h (RID_IS_FINAL): Add.

cp/ChangeLog:

        * 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.

ChangeLog:

        * doc/extend.texi (Type Traits): Add __is_final.

testsuite/ChangeLog:

        * g++.dg/ext/is_final.C: New.

Attachment: 51365-fe.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]