premerge-monolithic-windows build fails in the CI

[firewave]

It is not clear what is causing the failure in the current output which does not contain any error details.

It started with https://lab.llvm.org/buildbot/#/builders/35/builds/2200.

C:\BuildTools\VC\Tools\MSVC\14.29.30133\include\variant(474): fatal error C1060: compiler is out of heap space

C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): warning C4927: illegal conversion; more than one user-defined conversion has been implicitly applied
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): note: while calling the constructor 'Fortran::semantics::Symbol::Symbol(const Fortran::semantics::Symbol &) noexcept(false)'
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\include\flang\Semantics\symbol.h(959): note: compiler has generated 'Fortran::semantics::Symbol::Symbol' here
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(767): fatal error C1060: compiler is out of heap space

But that no longer seems to be the cause.

The job does use sccache so maybe the failure is related to that.

[llvmbot]

@llvm/issue-subscribers-flang-frontend

Author: Oliver Stöneberg (firewave)

It is not clear what is causing the failure in the current output which does not contain any error details.

It started with https://lab.llvm.org/buildbot/#/builders/35/builds/2200.

C:\BuildTools\VC\Tools\MSVC\14.29.30133\include\variant(474): fatal error C1060: compiler is out of heap space

C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): warning C4927: illegal conversion; more than one user-defined conversion has been implicitly applied
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): note: while calling the constructor 'Fortran::semantics::Symbol::Symbol(const Fortran::semantics::Symbol &) noexcept(false)'
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\include\flang\Semantics\symbol.h(959): note: compiler has generated 'Fortran::semantics::Symbol::Symbol' here
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(767): fatal error C1060: compiler is out of heap space

But that no longer seems to be the cause.

The job does use sccache so maybe the failure is related to that.

[firewave]

The initial (or additional different?) issue might have been with flang but now it isn't able to build a single source file.

[CaseyCarter]

It is not clear what is causing the failure in the current output which does not contain any error details.

It started with https://lab.llvm.org/buildbot/#/builders/35/builds/2200.

C:\BuildTools\VC\Tools\MSVC\14.29.30133\include\variant(474): fatal error C1060: compiler is out of heap space

C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): warning C4927: illegal conversion; more than one user-defined conversion has been implicitly applied
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(669): note: while calling the constructor 'Fortran::semantics::Symbol::Symbol(const Fortran::semantics::Symbol &) noexcept(false)'
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\include\flang\Semantics\symbol.h(959): note: compiler has generated 'Fortran::semantics::Symbol::Symbol' here
C:\ws\buildbot\premerge-monolithic-windows\llvm-project\flang\lib\Semantics\semantics.cpp(767): fatal error C1060: compiler is out of heap space

flang + std::variant has to be microsoft/STL#4959 which we fixed only very recently in microsoft/STL#4966 for VS 17.13 preview 1. VS17.13p1 won't ship for quite a while. Constraining the converting constructor of flang's InterfaceStmt type should workaround the issue (see the discussion starting at microsoft/STL#4959 (comment)).

EDIT: My knee may have jerked too fast in response to the "flang + variant" stimulus. The syndrome is different from microsoft/STL#4959: that was Clang-only due to some difference in how and when Clang and MSVC check the semantics of special member functions that I never pinned down. Once I found the fix, and decided it was a correctness issue in the STL, I didn't bother to keep digging in.

This case, however, is an MSVC failure so it may have a different root cause. Or a change in flang may have tweaked things just enough for MSVC to run into the STL's lack of short-circuiting in our constraints on variant. In any case, someone may want to investigate applying our suggested workaround to see if it unblocks the build.

EDIT HARDER: To save some investigation, our suggested workaround is:

 // Many classes below simply wrap a std::variant<> discriminated union,
 // which is conventionally named "u".
 #define UNION_CLASS_BOILERPLATE(classname) \
-  template <typename A, typename = common::NoLvalue<A>> \
+  template <typename A, typename = common::NoLvalue<A>, typename = std::enable_if_t<std::is_constructible<decltype(u), A>::value> \
   classname(A &&x) : u(std::move(x)) {} \
   using UnionTrait = std::true_type; \
   BOILERPLATE(classname)

[firewave]

This started working again with https://lab.llvm.org/buildbot/#/builders/35/builds/2958. There is a lot of changes in that build so it is hard to tell what fixed it.