Open firewave opened 3 days ago
@llvm/issue-subscribers-flang-frontend
Author: Oliver Stöneberg (firewave)
The initial (or additional different?) issue might have been with flang but now it isn't able to build a single source file.
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 https://github.com/microsoft/STL/issues/4959 which we fixed only very recently in https://github.com/microsoft/STL/pull/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 https://github.com/microsoft/STL/issues/4959#issuecomment-2357613419).
EDIT: My knee may have jerked too fast in response to the "flang + variant" stimulus. The syndrome is different from https://github.com/microsoft/STL/issues/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)
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.
But that no longer seems to be the cause.
The job does use
sccache
so maybe the failure is related to that.