From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 4430B3857C6E for ; Fri, 24 Sep 2021 12:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4430B3857C6E Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-362-kgzrxVkINbOUzvSxVMe3Lg-1; Fri, 24 Sep 2021 08:29:39 -0400 X-MC-Unique: kgzrxVkINbOUzvSxVMe3Lg-1 Received: by mail-ua1-f69.google.com with SMTP id m6-20020ab073c6000000b002b330799c9cso4095012uaq.2 for ; Fri, 24 Sep 2021 05:29:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9XXGs1Knd1hslgnCni2T+5HegLQN8ISolALFAvK9c+E=; b=3/xC0Ax0f4sM4j6WxuyVDe9tABPPjn28jXMgwu35Yxg1miXrrgzngc8qa8AgvZ8WY3 X7+zB0Yn6xbbiCtngxYE9wy9XzUS+AexfgCUT04TmM+ZB/jg2CQHKgKksXRXOPlG7fXH NpfSX+7a2hi1xxRWZEZCy0EtNFKXrjBD1L30sphFO+bPrFtDa+o4QtZXW+7vOMpvzwYl UmTxdd9Ii2Ux6YmN2nVas8HZYyD/eKferG1bnQENa+fp3+LQa8k/akRs5FQZAIf2FHEf uoxDJSNVZy7ZxuLFeXSd/YAMrL5bQMUjfrU+ix4JOIC+WnGP81jjq2eK7wTYTA1VSq42 gDkQ== X-Gm-Message-State: AOAM530ggOAwCPl+tiO2mXfQ2YATMsvqgbYUar3RealC4VNlWRXNGaaP X46vVeovj4n2T/042oPO17zg/x1vJmr9FoBmKEXEqqFAFHvWHxV+PVEoFpwQNjOHVESLFvWL4uY WApc0SgXD6R9XB8XzVvV+VEuZUm9f9Kg= X-Received: by 2002:ab0:3185:: with SMTP id d5mr8356919uan.73.1632486579475; Fri, 24 Sep 2021 05:29:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPrY6RyFzhSrXBJBG0iRZ+uhyT7FCVDXR+fJzWCbchbXAyyWDkKPtYQ/JV17Xqg86epSWOwMSt8AyDi2zx/yw= X-Received: by 2002:ab0:3185:: with SMTP id d5mr8356888uan.73.1632486579225; Fri, 24 Sep 2021 05:29:39 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Wakely Date: Fri, 24 Sep 2021 13:29:28 +0100 Message-ID: Subject: RFC: Remove and _GLIBCXX_CONCEPT_CHECKS To: "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2021 12:29:44 -0000 I would like to remove the feature described at https://gcc.gnu.org/onlinedocs/libstdc++/manual/concept_checking.html As it says at the end of that page, the checks have never been updated for C++11 requirements, which were relaxed in many ways (e.g. only requiring movable not copyable). Currently if you enable the concept checks there are a little over a hundred test failures (fewer than I was expecting!). Many of these are because we have extensions like allowing the "wrong" allocator to be used with a container (e.g. vector>) which gets rejected by the concept checks. Some of the concepts aren't even correctly defined for C++98, e.g. template struct _ConvertibleConcept { void __constraints() { _To __y _IsUnused = __x; } _From __x; }; This implicitly requires that _To is destructible, but we use it in places where that isn't required, e.g. std::move_backward and std::copy_backward. In fact, neither of those requires this concept at all, they only require assignable. So it's just wrong. And the diagnostics you get from failed concept checks are not great either: In file included from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/concept_check.h:56, from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator_base_funcs.h:64, from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:66, from /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:60, from /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/allocator/construction.cc:20: /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h: In instantiation of 'void __gnu_cxx::_ConvertibleConcept<_From, _To>::__constraints() [with _From = X; _To = X]': /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h:62: required from 'constexpr void __gnu_cxx::__function_requires() [with _Concept = __gnu_cxx::_ConvertibleConcept]' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:889: required from '_BI2 std::move_backward(_BI1, _BI1, _BI2) [with _BI1 = X*; _BI2 = X*]' /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:534: required from 'void std::vector<_Tp, _Alloc>::_M_fill_insert(std::vector<_Tp, _Alloc>::iterator, std::vector<_Tp, _Alloc>::size_type, const std::vector<_Tp, _Alloc>::value_type&) [with _Tp = X; _Alloc = TaggingAllocator; std::vector<_Tp, _Alloc>::iterator = std::vector >::iterator; std::vector<_Tp, _Alloc>::size_type = long unsigned int; std::vector<_Tp, _Alloc>::value_type = X] /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/allocator/construction.cc:95: required from here /home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/boost_concept_check.h:223: error: use of deleted function 'X::X(const X&)' /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/allocator/construction.cc:78: note: declared here The error happens inside the header, not from the std::move_backward function where we are trying to enforce the (wrong) concept. This was clever tech for C++98, but with type traits and static assertions we can do so much better nowadays. We could spend time updating all these concepts and auditing that we use them correctly, or we could leave them broken and unusable for anything after C++98, or we could remove them. I'd like to remove them. In some cases it would be good to add a static_assert (only for C++11 and later, of course) to enforce the *correct* requirements, with much better diagnostics. But I'd like to do that at the same time as ripping out these old checks. Any objections?