Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
> Is just using std::terminate as the handler viable? Or if we're sure > contracts in some form will go into the IS eventually, and the > signature won't change, we could just add it in __cxxabiv1:: as you > suggested earlier. No, the handler needs to be configurable (at least quietly) in order to support experimentation by SG21. No idea if it will stay that way. Andrew
Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
On Wed, 14 Jul 2021 at 04:56, Jason Merrill wrote: > > On 7/12/21 3:58 PM, Jonathan Wakely wrote: > > On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: > >> > >> On 6/26/21 10:23 AM, Andrew Sutton wrote: > >>> > >>> I ended up taking over this work from Jeff (CC'd on his existing email > >>> address). I scraped all the contracts changes into one big patch > >>> against master. See attached. The ChangeLog.contracts files list the > >>> sum of changes for the patch, not the full history of the work. > >> > >> Jonathan, can you advise where the library support should go? > >> > >> In N4820 was part of the language-support clause, which makes > >> sense, but it uses string_view, which brings in a lot of the rest of the > >> library. Did LWG talk about this when contracts went in? How are > >> freestanding implementations expected to support contracts? > > > > I don't recall that being discussed, but I think I was in another room > > for much of the contracts review. > > > > If necessary we could make the std::char_traits specialization > > available freestanding, without the primary template (or the other > > specializations). But since C++20 std::string_view also depends on > > quite a lot of ranges, which depends on iterators, which is not > > freestanding. Some of those dependencies were added more recently than > > contracts was reviewed and then yanked out, so maybe wasn't considered > > a big problem back then. In any case, depending on std::string_view > > (even without the rest of std::basic_string_view) is not currently > > possible for freestanding. > > I guess I'll change string_view to const char* for now. I think that's best. Making std::string_view usable would take some work. > >> I imagine the header should be for now. > > > > Agreed. > > And the type std::experimental::??::contract_violation. Maybe > contracts_v1 for the inline namespace? LGTM > Did you have any thoughts about the violation handler? Is it OK to add > a default definition to the library, in the above namespace? I'd rather not have any std::experimental::* symbols go into the DSO. For std::experimental::filesystem we added libstdc++fs.a, with no corresponding .so library, which users need to link to explicitly to use that TS. Would something like libstdc++contracts.a work here? Is it just one symbol? Aside: Ulrich Drepper suggested recently that the driver should have been updated to automatically add -lstdc++fs so that using was seamless, as the archive contents wouldn't be used unless something in the program referred to the symbols in it. Is just using std::terminate as the handler viable? Or if we're sure contracts in some form will go into the IS eventually, and the signature won't change, we could just add it in __cxxabiv1:: as you suggested earlier.
Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
On 7/12/21 3:58 PM, Jonathan Wakely wrote: On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of changes for the patch, not the full history of the work. Jonathan, can you advise where the library support should go? In N4820 was part of the language-support clause, which makes sense, but it uses string_view, which brings in a lot of the rest of the library. Did LWG talk about this when contracts went in? How are freestanding implementations expected to support contracts? I don't recall that being discussed, but I think I was in another room for much of the contracts review. If necessary we could make the std::char_traits specialization available freestanding, without the primary template (or the other specializations). But since C++20 std::string_view also depends on quite a lot of ranges, which depends on iterators, which is not freestanding. Some of those dependencies were added more recently than contracts was reviewed and then yanked out, so maybe wasn't considered a big problem back then. In any case, depending on std::string_view (even without the rest of std::basic_string_view) is not currently possible for freestanding. I guess I'll change string_view to const char* for now. I imagine the header should be for now. Agreed. And the type std::experimental::??::contract_violation. Maybe contracts_v1 for the inline namespace? Did you have any thoughts about the violation handler? Is it OK to add a default definition to the library, in the above namespace? Jason
Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: > > On 6/26/21 10:23 AM, Andrew Sutton wrote: > > > > I ended up taking over this work from Jeff (CC'd on his existing email > > address). I scraped all the contracts changes into one big patch > > against master. See attached. The ChangeLog.contracts files list the > > sum of changes for the patch, not the full history of the work. > > Jonathan, can you advise where the library support should go? > > In N4820 was part of the language-support clause, which makes > sense, but it uses string_view, which brings in a lot of the rest of the > library. Did LWG talk about this when contracts went in? How are > freestanding implementations expected to support contracts? I don't recall that being discussed, but I think I was in another room for much of the contracts review. If necessary we could make the std::char_traits specialization available freestanding, without the primary template (or the other specializations). But since C++20 std::string_view also depends on quite a lot of ranges, which depends on iterators, which is not freestanding. Some of those dependencies were added more recently than contracts was reviewed and then yanked out, so maybe wasn't considered a big problem back then. In any case, depending on std::string_view (even without the rest of std::basic_string_view) is not currently possible for freestanding. > I imagine the header should be for now. Agreed.
Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
On 7/5/21 3:07 PM, Jason Merrill wrote: On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of changes for the patch, not the full history of the work. Jonathan, can you advise where the library support should go? In N4820 was part of the language-support clause, which makes sense, but it uses string_view, which brings in a lot of the rest of the library. Did LWG talk about this when contracts went in? How are freestanding implementations expected to support contracts? I imagine the header should be for now. You've previously mentioned that various current experimental features don't appear in libstdc++.so; that is not true of the current patch. I see that https://github.com/arcosuc3m/clang-contracts takes the approach, of teaching the compiler about std::contract_violation, building up an object, and passing it to the handler directly, much like we do for initializer_list. Their equivalent of __on_contract_violation is an internal function emitted in each translation unit that needs it, so it doesn't need to affect the library ABI. These both seem like improvements to me. More complicated is the question of the default violation handler: the lock3 implementation calls it "handle_contract_violation" in the global namespace, and overriding it is done with ELF symbol interposition, much like the replaceable allocation functions. That approach seems reasonable, but I'd think we should use a reserved name, e.g. ::__handle_contract_violation or __cxxabiv1::__contract_violation_handler. The clang implementation above involves specifying the name of the handler on the compiler command line, which seems problematic, as it would tend to mean multiple independent violation handlers active at the same time. Their default handler is std::terminate, which does avoid needing to add the default handler to the library. I've pushed the patch with my adjustments so far to devel/c++-contracts on gcc.gnu.org. One of those adjustments was changing the contract_violation data members to be const char *, to make creating an object easier, and making the member functions inline, to reduce the number of symbols added to the library. Jason
contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)
On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of changes for the patch, not the full history of the work. Jonathan, can you advise where the library support should go? In N4820 was part of the language-support clause, which makes sense, but it uses string_view, which brings in a lot of the rest of the library. Did LWG talk about this when contracts went in? How are freestanding implementations expected to support contracts? I imagine the header should be for now. You've previously mentioned that various current experimental features don't appear in libstdc++.so; that is not true of the current patch. I see that https://github.com/arcosuc3m/clang-contracts takes the approach, of teaching the compiler about std::contract_violation, building up an object, and passing it to the handler directly, much like we do for initializer_list. Their equivalent of __on_contract_violation is an internal function emitted in each translation unit that needs it, so it doesn't need to affect the library ABI. These both seem like improvements to me. More complicated is the question of the default violation handler: the lock3 implementation calls it "handle_contract_violation" in the global namespace, and overriding it is done with ELF symbol interposition, much like the replaceable allocation functions. That approach seems reasonable, but I'd think we should use a reserved name, e.g. ::__handle_contract_violation or __cxxabiv1::__contract_violation_handler. The clang implementation above involves specifying the name of the handler on the compiler command line, which seems problematic, as it would tend to mean multiple independent violation handlers active at the same time. Their default handler is std::terminate, which does avoid needing to add the default handler to the library. Jason
