On Tue, 18 Jan 2022 at 11:01, Jonathan Wakely <jwak...@redhat.com> wrote:
> > > On Mon, 17 Jan 2022 at 14:01, Ben Beasley <c...@musicinmybrain.net> wrote: > >> Skimming through Koschei, here are a sampling of regressions that seem >> to be associated with GCC 12. Some of these are in packages I maintain >> directly; others are via @neuro-sig. >> >> With a few exceptions, I have triaged these only to the extent of >> confirming the problem appeared at the same time as GCC 12 and noting >> the initial error. I mostly haven’t gotten around to filing or searching >> for bugs, upstream or downstream. >> >> Explicit deletion of the >> std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems >> like it is going to be a popular cause of FTBFS in C++ packages. Use of >> this constructor mostly happens implicitly. I think explicit use of the >> default constructor, e.g. std::string_view(), will usually be the >> simplest correct substitute. >> > > All such uses were undefined behaviour (and should have thrown an > exception at runtime if the code was ever executed. Fixing those is good. > That change now only applies when compiling as C++23, so won't affect most packages (once the fix makes it from upstream GCC to rawhide). It would still be good to fix code that really does construct strings and string_views from nullptr, otherwise it will break again in a few years when GCC defaults to -std=gnu++23. > > >> New compilation errors: >> >> COPASI: “error: passing 'const CDataVectorN<CCopasiTask>' as 'this' >> argument discards qualifiers [-fpermissive]” >> > > What's the context? Is that being used as a comparison function in a std:: > container or something? > > >> >> grpc: initializing std::string_view/absl::string_view with nullptr – >> fixed and PR sent upstream >> >> python-steps: “static assertion failed: key equality predicate must be >> invocable with two arguments of key type” via >> c++/12/bits/hashtable_policy.h >> > > Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923 > > > >> >> vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string<char>' >> is ambiguous” – looks like an attempt to initialize a string by >> std::string(nullptr), which is now explicitly deleted >> (“basic_string(nullptr_t) = delete”) >> > > If it's actually initializing it with nullptr, that's just undefined (and > going to be ill-formed in C++23) and the code should be fixed. > > If it's like the nlohmann:json case, I need to investigate more whether > it's a defect in the C++23 spec or the code should be fixed. > Turns out it's both. The C++23 change breaks the json lib (and they have a fix) but I made it apply to all of C++11/14/17/20/23, which is incorrect because it breaks code that should be valid in C++20. Fixed in GCC upstream now.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
