[cfe-dev] Old bug, not yet looked at

[JVApen via cfe-dev]

Looks like we'll have to upgrade the STL we are using to a more recent
version of MSVC.

I prefer the diagnostic that MSVC gives, which will be there after that
upgrade. As Clang is the second compiler, the code should already be
correct.

The thing that I'm most worried about is that I as a naive user should be
aware of the implementation details of std::function to either use an
include or a forward declare, as I expected this is_convertable to only be
evaluated when constructing that function with a callable. However, that's
an issue for another forum.

Thanks for all the effort!


On Tue, Feb 5, 2019, 01:36 Casey Carter <Casey at carter.net wrote:

> On Mon, Feb 4, 2019 at 3:22 PM Reid Kleckner via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> I see there is an update suggesting that this is an issue in the STL:
>> https://bugs.llvm.org/show_bug.cgi?id=32072#c3
>>
>> However, I think there is still an argument to be made that clang should
>> "do what MSVC does" here. I suppose it's not clear what that is, though.
>>
>
> Recentish (IIRC since roughly VS2017 15.8) versions of MSVC would diagnose
> the attempt to evaluate __is_convertible_to(T, U) for an incomplete class
> type T as ill-formed. Clang, IIUC, simply yields `false`. (The behavior of
> a program that evaluates `std::is_convertible<T, U>` for an incomplete
> class type T is formally undefined per http://eel.is/c++draft/meta#rqmts-5,
> so both implementations are conforming depending on the reader's
> interpretation of "undefined behavior" vs. "ill-formed with no diagnostic
> required".)
>
> Note that neither behavior allows the subject program to compile and do
> what the submitter expects: changing clang to mirror the MSVC behavior
> would result in the program being ill-formed with a diagnostic instead of
> being ill-formed due to ODR violation. Doing as the submitter expects
> requires a change to the Standard Library to avoid asking the broken
> question in the first place.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190205/cd293361/attachment.html>