Old bug, not yet looked at

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Old bug, not yet looked at

David Blaikie via cfe-dev
Hello all,

A long time ago, I've logged a bug about`std::function` being broken because of a type trait. See https://bugs.llvm.org/show_bug.cgi?id=32072

It has been over 1.5 years and it still hasn't bee looked at. This while I have to keep telling my colleagues they need unnecessary includes because of a bug in clang-cl.

I know 8.0.0 is on its way, though could it be possible to take a look at this?

JVApen

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Old bug, not yet looked at

David Blaikie via cfe-dev
I see there is an update suggesting that this is an issue in the STL:

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.

On Thu, Jan 31, 2019 at 11:29 PM JVApen via cfe-dev <[hidden email]> wrote:
Hello all,

A long time ago, I've logged a bug about`std::function` being broken because of a type trait. See https://bugs.llvm.org/show_bug.cgi?id=32072

It has been over 1.5 years and it still hasn't bee looked at. This while I have to keep telling my colleagues they need unnecessary includes because of a bug in clang-cl.

I know 8.0.0 is on its way, though could it be possible to take a look at this?

JVApen
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Old bug, not yet looked at

David Blaikie via cfe-dev
On Mon, Feb 4, 2019 at 3:22 PM Reid Kleckner via cfe-dev <[hidden email]> wrote:
I see there is an update suggesting that this is an issue in the STL:

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.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Old bug, not yet looked at

David Blaikie 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 <[hidden email] wrote:
On Mon, Feb 4, 2019 at 3:22 PM Reid Kleckner via cfe-dev <[hidden email]> wrote:
I see there is an update suggesting that this is an issue in the STL:

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.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev