uvw: Build error with vs2019

I try to use v1.16.0_libuv-v1.28 release on Visual Studio 2019, and I got following errors: image Here are part of the compiler output:

1>------ Build started: Project: Server, Configuration: Debug x64 ------
1>pch.cpp
1>C:\source\Server\include\uvw\lib.hpp(68,1): error C3537:  you cannot cast to a type that contains 'auto'
1>C:\source\Server\include\uvw\lib.hpp(68,1): message :  This diagnostic occurred in the compiler generated function 'F *uvw::SharedLib::sym(std::string)'
1>C:\source\Server\include\uvw\lib.hpp(68,1): error C2100:  illegal indirection
1>C:\source\Server\include\uvw\lib.hpp(68,1): message :  This diagnostic occurred in the compiler generated function 'F *uvw::SharedLib::sym(std::string)'
1>C:\source\Server\include\uvw\thread.hpp(109,36): warning C4838:  conversion from 'uvw::Flags<uvw::Thread::Options>' to 'unsigned int' requires a narrowing conversion
1>C:\source\Server\include\uvw\thread.hpp(165,1): error C3537:  you cannot cast to a type that contains 'auto'
1>C:\source\Server\include\uvw\thread.hpp(165,1): message :  This diagnostic occurred in the compiler generated function 'T *uvw::ThreadLocalStorage::get(void) noexcept'
1>C:\source\Server\include\uvw\thread.hpp(165,1): error C2100:  illegal indirection

My cl.exe version is Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27619.1 for x64

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 19 (8 by maintainers)

Most upvoted comments

UVW Compiles successfully in the latest Visual Studio update 16.3.4

Good to know, but what can I do with a compiler bug I cannot even reproduce?

First I would say, report it, AFAIK the MSVC team would appreciate such feedback. Meanwhile I’ll try to figure out a workaround.

I have tried to report it here.

No idea @Merethiel - I’m not using Windows and this problem doesn’t really depend on me, so I cannot do much. The issue is open only to track it and avoid duplicates but you should rather ask MS when they plan to accept valid C++ with their compiler.

So, it’s confirmed that the bug is in VS, right?
I’ll mark the issue as won’t fix. Please, close it when the fix is upstream.
Thanks.

I’ve just run the sample code, it does fail with cl 19.21.27619.1 (a.k.a 16.1.0 Preview 3) but works just fine with 19.20.27508.1 (a.k.a. 16.0.3), so I’d say it’s most likely a compiler bug. Bug could be either that it compiles with 19.20 or that it fails with 19.21, as I’d expect code to compile the same for a semver-minor version change.