[Bug c++/95606] New: [10/11 regression] <any> conflicts with std::is_constructible

[Bug c++/95606] New: [10/11 regression] <any> conflicts with std::is_constructible

[kuzniar95 at o2 dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606

            Bug ID: 95606
           Summary: [10/11 regression] <any> conflicts with
                    std::is_constructible
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kuzniar95 at o2 dot pl
  Target Milestone: ---

Created attachment 48713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48713&action=edit
main.ii + verbose gcc invoke command

Hi! I'm coming from nlohmann/json project on GitHub where we detected a
possible regression in GCC 10 and later.

Please follow this link for details:
https://github.com/nlohmann/json/issues/2129 You will find minimal code example
there with some detailed analysis of "compilation path" but I need your help
whether it actually is a regression or not. For example, I'm not sure if the
compiler should jump from decltype(swap(std::declval<_Tp&>(),
std::declval<_Tp&>())) with some implicit conversions to std::any constructor
(maybe it should be inaccessible) as clang seems to dismiss std::any which I
discovered by poisoning std::any constructor. I'm also attaching some files as
requested by "bug reporting instructions".

Even if you think GCC works fine, maybe it could be improved so it gives better
error messages in the future in such convoluted scenarios. Please let me know
what you think.

P.S. I've taken a while to bisect and build GCC compilers and I discovered this
was the first broken commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=608a080c3f6e5a8338ff99658b27e226cbba7a67

[Bug libstdc++/95606] [10/11 regression] <any> conflicts with std::is_constructible

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2
           Keywords|                            |rejects-valid

[Bug libstdc++/95606] [10/11 regression] <any> conflicts with std::is_constructible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The testcase is:

#include <any>
#include <string>

template<typename>
class basic_json;

using json = basic_json<std::string>;

class json_ref
{
  public:
    template <typename T,
              bool = std::is_constructible<json, T>::value>
    json_ref(T &&){}
};

template<typename>
class basic_json
{
  public:
    basic_json(json_ref) {}
};

namespace std {

template<>
void swap<json>(json&, json&) noexcept {}

}

int main() {}


This fails when compiled with -std=gnu++17 or later.

Specializing std::swap like this is wrong (and in C++20 explicitly results in
undefined behaviour). Replacing it with a normal overload in the same namespace
as the type avoids the error.

Do you have an example that doesn't involve a bogus specialization in namespace
std?

[Bug libstdc++/95606] [10/11 regression] <any> conflicts with std::is_constructible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this is not a bug in GCC. A specialization of std::swap still depends
on the signature of the primary template, and that primary template requires
the argument types to be swappable. The is_swappable trait requires
move_constructible, and that requires complete types. Checking
is_move_constructible<json> will perform overload resolution which considers
the basic_json(json_ref) constructor, which tries to see if json_ref can be
constructed from a basic_json rvalue, which checks the constraint on the
json_ref constructor, which depends on basic_json, which is incomplete at this
point.

The json code is incorrect and should be fixed.

The std::swap<json> specialization is wrong and should be replaced by a normal
(non-template) overload in the same namespace as the json type:

void swap(json&, json&) noexcept;

The json_ref constructor should be constrained to avoid recursive
instantiations with incomplete types, e.g.

template<typename T, typename U>
  using is_not = std::is_same<std::remove_cv_t<std::remove_reference_t<T>>, U>;

class json_ref
{
  public:
    template <typename T,
              typename = std::enable_if_t<!is_not<T, json_ref>::value>,
              typename = std::enable_if_t<!is_not<T, json>::value>,
              bool = std::is_constructible<json, T>::value>
    json_ref(T &&){}
};

[Bug libstdc++/95606] [10/11 regression] <any> conflicts with std::is_constructible

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And probably one or both of the basic_json and json_ref constructors should be
explicit, so that you can't implicitly convert them both to each other.