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:
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)
UVW Compiles successfully in the latest Visual Studio update 16.3.4
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 with19.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 with19.20or that it fails with19.21, as I’d expect code to compile the same for a semver-minor version change.