Bug 215003 – [MSVC] wtf/Optional.h: error C2280: 'WTF::constexpr_storage_t<T> &WTF::constexpr_storage_t<T>::operator =(const WTF::constexpr_storage_t<T> &)': attempting to reference a deleted function

• Component: New Bugs
• Status: RESOLVED FIXED

[QuellaZhang]

Created attachment 405653 [details]
build_log

Environment:
VS 2019 + Windows Server 2016

Issue description:
We tried to build WebKit using VS2019 on Windows Server 2016. WebKit failed to build due to error C2280: 'WTF::constexpr_storage_t<T> &WTF::constexpr_storage_t<T>::operator =(const WTF::constexpr_storage_t<T> &)': attempting to reference a deleted function on windows with MSVC. It can be reproduced on master branch latest commit 4d2d7cb. Could you please help take a look at this? Thanks in advance!

Repro steps:
1. git clone https://github.com/WebKit/webkit F:\gitP\WebKit\webkit
2. open a VS 2019 x64 command prompt as admin and browse to F:\gitP\WebKit\webkit
3. set path=F:\tools\WebKit\tools;%path%
4. extra WebKitRequirementsWin64 to F:\gitP\WebKit\webkit\WebKitLibraries\win
5. mkdir build_amd64 && pushd build_amd64
6. cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_SYSTEM_VERSION=10.0.18362.0 -DCMAKE_BUILD_TYPE=Release -DRUBY_LIBRARY=C:\tools\ruby26\lib -DPORT="WinCairo" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DSHOW_BINDINGS_GENERATION_PROGRESS=1 -DDEVELOPER_MODE=ON -DENABLE_EXPERIMENTAL_FEATURES=ON ..
7. msbuild /p:Platform=x64 /p:Configuration=Release WebKit.sln /t:Rebuild

Actual result:
F:\gitP\WebKit\webkit\build_amd64\WTF\Headers\wtf/Optional.h(419,39): error C2280: 'WTF::constexpr_storage_t<T> &WTF::constexpr_storage_t<T>::operator =(const WTF::constexpr_storage_t<T> &)': attempting to reference a deleted function [F:\gitP\WebKit\webkit\build_amd64\Source\JavaScriptCore\JavaScriptCore.vcxproj]

[Fujii Hironori]

I don't see any compilation errors for WinCairo trunk@265079.
> perl Tools\Scripts\build-webkit --wincairo --release

I'm using:

Visual Studio 2019 version 16.6.5
Windows 10 SDK (10.0.19041.0)
Windows 10 ver.1903 64bit

What's the difference?

[Fujii Hironori]

This is my cl.exe version

Microsoft (R) C/C++ Optimizing Compiler Version 19.26.28806 for x64

[Fujii Hironori]

This seems a MSVC issue. Please report it to Microsoft.

[QuellaZhang]

Hi Fujii,

Thanks for your info. We use open source projects to test the unreleased version of vs. We will report it to VC++ Team. 

Thanks,
Lin

[QuellaZhang]

Hi Fujii,

VC++ Team feedback detailed as below: 

Nope: this is not a compiler issue. The problem is this code:

  constexpr Optional(const Optional& rhs)
  : OptionalBase<T>()
  {
    if (rhs.initialized()) {
        if constexpr (std::is_trivially_copyable_v<T>)
            OptionalBase<T>::storage_ = *rhs;
        else
            ::new (static_cast<void*>(dataptr())) T(*rhs);
        OptionalBase<T>::init_ = true;
    }
  }

In C++ the definition of std::is_trivially_copyable is currently:

"A trivially copyable class is a class:

   - that has at least one eligible copy constructor, move constructor, copy assignment operator, or move

     assignment operator (11.4.3, 11.4.4.2, 11.4.5),

   - where each eligible copy constructor, move constructor, copy assignment operator, and move assignment

     operator is trivial, and

   - that has a trivial, non-deleted destructor(11.4.6)."

And std::pair<JSC::SamplingProfiler::StackFrame::CodeLocation,JSC::CodeBlock *> meets the conditions of this definition. Note: just because a class meets the conditions of std::is_trivially_copyable doesn't mean it is trivially copyable in all circumstances it just means there exists at least one condition under which it would be trivially copyable. Note: if I change the definition of the function above to use 'std::is_trivially_copy_assignable_v' instead of 'std::is_trivially_copyable_v' then the code compiles. I also had to change the move-constructor just below.


We used unreleased version of vs as below:
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29129.96 for x64 

I've attached the UnifiedSource-f2e18ffc-32.i file. 

cl.exe /c /std:c++17 /TP UnifiedSource-f2e18ffc-32.i can reproduced this issue. If we tried to use 'std::is_trivially_copy_assignable_v' instead of 'std::is_trivially_copyable_v' in this UnifiedSource-f2e18ffc-32.i file. We can compile pass. Could you please take a look at this issue again? Thanks in advance!

Thanks,
Lin

[QuellaZhang]

Created attachment 405904 [details]
UnifiedSource-f2e18ffc-32.cpp Precompiled file

[Fujii Hironori]

std::is_trivially_copyable_v was added by r262252.

Bug 212383 – for-of should check the iterable is a JSArray for FastArray in DFG iterator_open

[Fujii Hironori]

Created attachment 405940 [details]
Patch

[Yusuke Suzuki]

Comment on attachment 405940 [details]
Patch

r=me

[Fujii Hironori]

Thank you for the review.

jsc testing EWS failed wasm.yaml/wasm/lowExecutableMemory/imports-oom.js.default-wasm.
However, the test case seems flaky on EWS. Other patch also failed it flakily.
https://ews-build.webkit.org/#/builders/1/builds/19563

[Fujii Hironori]

Comment on attachment 405940 [details]
Patch

Clearing flags on attachment: 405940

Committed r265265: <https://trac.webkit.org/changeset/265265>

[Fujii Hironori]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/66546102>