[cfe-users] Code which compiles with g++ but not with clang++

[connor horman via cfe-users]

I've actually reduced the problem to the defaulted copy assignment operator
itself:
gcc: https://godbolt.org/z/83Gjdb
clang: https://godbolt.org/z/z35x4K

The controlling clause would seem to be
https://eel.is/c++draft/class.copy.assign#7.4. In particular, because
overload resolution cannot find this->_m.operator=(rhs._m), the operator
should be defined as deleted (which seems to be the behaviour of gcc,
https://godbolt.org/z/bs5aPY).

On Thu, 5 Nov 2020 at 11:08, connor horman <chorman64 at gmail.com> wrote:

>
>
> On Thu, Nov 5, 2020 at 11:06 connor horman <chorman64 at gmail.com> wrote:
>
>> Looking at https://eel.is/c++draft/optional.optional and
>> optional.assign, it shouldn't be ill-formed to have a non
>> copy-constructible type, the copy constructor of optional should be defined
>> as deleted.
>> [optional.optional.general] clause 3 "T shall be a type other than cv
>> in_place_t or cv nullopt_t that meets the Cpp17Destructible requirements"
>> [optional.assign] clause 7 "This operator is defined as deleted unless
>> is_copy_constructible_v<T> is true and is_copy_assignable_v<T> is true"
>>
>> I presume it's the same or similar in both C++17 and C++20 (published)
>> (with Cpp17Destructible being just Destructible in C++17).
>>
>>
>> On Thu, Nov 5, 2020 at 10:07 Pavel Černohorský via cfe-users <
>> cfe-users at lists.llvm.org> wrote:
>>
>>> On 05. 11. 20 15:47, Marshall Clow via cfe-users wrote:
>>>
>>> I tried this code on compiler explorer.
>>> It compiles w/o error with clang + libc++
>>> It fails to compile with clang and libstdc++
>>>
>>> The error message given is:
>>>
>>> In file included from <source>:1:
>>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:158:7:
>>> error: the parameter for this explicitly-defaulted copy assignment operator
>>> is const, but a member or base requires it to be non-const
>>>      operator=(const _Optional_payload_base&) = default;
>>>      ^
>>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:357:7:
>>> note: in instantiation of template class 'std::_Optional_payload_base<S>'
>>> requested here
>>>    : _Optional_payload_base<_Tp>
>>>      ^
>>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:631:30:
>>> note: in instantiation of template class 'std::_Optional_payload<S, true,
>>> false, false>' requested here
>>>      _Optional_payload<_Tp> _M_payload;
>>>                             ^
>>> /opt/compiler-explorer/gcc-10.2.0/lib/gcc/x86_64-linux-gnu/10.2.0/../../../../include/c++/10.2.0/optional:660:15:
>>> note: in instantiation of template class 'std::_Optional_base<S, true,
>>> true>' requested here
>>>    : private _Optional_base<_Tp>,
>>>              ^
>>> <source>:10:20: note: in instantiation of template class
>>> 'std::optional<S>' requested here
>>>  std::optional<S> a;
>>>                   ^
>>> 1 error generated.
>>>
>>> I got exactly the same error, but the question is why. Shouldn't both
>>> g++ and clang++ behave the same way even on the libstdc++ (which is the
>>> default library clang uses on a lot of distros)? Is this gcc being too
>>> permissive to some bug in libstdc++ or is it a clang bug? Should I file a
>>> bug report to clang?
>>> _______________________________________________
>>> cfe-users mailing list
>>> cfe-users at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20201105/44f431ca/attachment.html>