On Tue, 18 Jan 2022 at 11:01, Jonathan Wakely <jwakely@xxxxxxxxxx> wrote:
On Mon, 17 Jan 2022 at 14:01, Ben Beasley <code@xxxxxxxxxxxxxxxxxx> 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.hMaybe 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
