v10.x does not compile with clang++ 11

[sam-github]

I'm not sure if this is a general problem, or just a problem for me, since I'm using clang 11 on Linux, and try not to have to change the compiler I use depending on the LTS branch I'm building.

As clang 11 becomes more common, maybe other people will notice this.

Interestingly, @nodejs/build doesn't specificy "maximum" supported compiler versions, just minimum, so whether its expected that as new versions of supported compilers come out our LTS branches will work with them might be a grey areas.

@nodejs/v8 Is this expected? Does it have an easy patch? If not, we can just close this, and I'll deal with it in my local dev environment.

• Version: 10.x-staging
• Platform: Linux
• Subsystem:

What steps will reproduce the bug?

export CC=clang-11 CXX=clang++-11 LD=clang++-11

exec ./configure --ninja --verbose

Build fails with:

core/lts (v10.x-staging $% u=) % ninja -C out/Release node -k0 -v
ninja: Entering directory `out/Release'
[1/678] clang++-11 -MMD -MF obj/deps/v8/src/torque/torque.ast-generator.o.d -DV8_GYP_BUILD -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=0 -DOPENSSL_NO_PINSHARED -DV8_TARGET_ARCH_X64 '-DV8_EMBEDDER_STRING="-node.56"' -DENABLE_DISASSEMBLER -DV8_PROMISE_INTERNAL_FIELD_COUNT=1 -DV8_INTL_SUPPORT -DV8_CONCURRENT_MARKING -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DANTLR4CPP_STATIC -I../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src -I../../deps/v8/src/torque -I../../deps/v8 -Wno-type-limits -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections  -O3 -O3 -fno-omit-frame-pointer -std=gnu++1y  -c ../../deps/v8/src/torque/ast-generator.cc -o obj/deps/v8/src/torque/torque.ast-generator.o
FAILED: obj/deps/v8/src/torque/torque.ast-generator.o
clang++-11 -MMD -MF obj/deps/v8/src/torque/torque.ast-generator.o.d -DV8_GYP_BUILD -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=0 -DOPENSSL_NO_PINSHARED -DV8_TARGET_ARCH_X64 '-DV8_EMBEDDER_STRING="-node.56"' -DENABLE_DISASSEMBLER -DV8_PROMISE_INTERNAL_FIELD_COUNT=1 -DV8_INTL_SUPPORT -DV8_CONCURRENT_MARKING -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DANTLR4CPP_STATIC -I../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src -I../../deps/v8/src/torque -I../../deps/v8 -Wno-type-limits -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections  -O3 -O3 -fno-omit-frame-pointer -std=gnu++1y  -c ../../deps/v8/src/torque/ast-generator.cc -o obj/deps/v8/src/torque/torque.ast-generator.o
In file included from ../../deps/v8/src/torque/ast-generator.cc:8:
In file included from ../../deps/v8/src/torque/ast-generator.h:8:
In file included from ../../deps/v8/src/torque/TorqueBaseVisitor.h:11:
In file included from ../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/./antlr4-runtime.h:32:
In file included from ../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/LexerInterpreter.h:9:
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/Vocabulary.h:19:15: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  Vocabulary& operator=(Vocabulary const&) = default;
              ^
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/Vocabulary.h:191:34: note: copy assignment operator of 'Vocabulary' is implicitly deleted because field '_literalNames' has no copy assignment operator
  std::vector<std::string> const _literalNames;
                                 ^
In file included from ../../deps/v8/src/torque/ast-generator.cc:8:
In file included from ../../deps/v8/src/torque/ast-generator.h:8:
In file included from ../../deps/v8/src/torque/TorqueBaseVisitor.h:11:
In file included from ../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/./antlr4-runtime.h:55:
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/atn/ATNConfig.h:94:14: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  ATNConfig& operator=(ATNConfig const&) = default;
             ^
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/atn/ATNConfig.h:39:16: note: copy assignment operator of 'ATNConfig' is implicitly deleted because field 'alt' is of const-qualified type 'const size_t' (aka 'const unsigned long')
  const size_t alt;
               ^
In file included from ../../deps/v8/src/torque/ast-generator.cc:8:
In file included from ../../deps/v8/src/torque/ast-generator.h:8:
In file included from ../../deps/v8/src/torque/TorqueBaseVisitor.h:11:
In file included from ../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/./antlr4-runtime.h:148:
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/tree/pattern/ParseTreeMatch.h:51:19: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  ParseTreeMatch& operator=(ParseTreeMatch const&) = default;
                  ^
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/tree/pattern/ParseTreeMatch.h:21:27: note: copy assignment operator of 'ParseTreeMatch' is implicitly deleted because field '_pattern' is of reference type 'const antlr4::tree::pattern::ParseTreePattern &'
  const ParseTreePattern& _pattern;
                          ^
In file included from ../../deps/v8/src/torque/ast-generator.cc:8:
In file included from ../../deps/v8/src/torque/ast-generator.h:8:
In file included from ../../deps/v8/src/torque/TorqueBaseVisitor.h:11:
In file included from ../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/./antlr4-runtime.h:149:
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/tree/pattern/ParseTreePattern.h:34:21: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  ParseTreePattern& operator=(ParseTreePattern const&) = default;
                    ^
../../deps/v8/third_party/antlr4/runtime/Cpp/runtime/src/tree/pattern/ParseTreePattern.h:97:13: note: copy assignment operator of 'ParseTreePattern' is implicitly deleted because field 'patternRuleIndex' is of const-qualified type 'const int'
  const int patternRuleIndex;
            ^
../../deps/v8/src/torque/ast-generator.cc:123:32: error: type 'antlr4::tree::TerminalNode *' cannot be narrowed to 'bool' in initializer list [-Wc++11-narrowing]
  ParameterList result{{}, {}, context->VARARGS(), {}};
                               ^~~~~~~~~~~~~~~~~~
../../deps/v8/src/torque/ast-generator.cc:123:32: note: insert an explicit cast to silence this issue
  ParameterList result{{}, {}, context->VARARGS(), {}};
                               ^~~~~~~~~~~~~~~~~~
                               static_cast<bool>()
../../deps/v8/src/torque/ast-generator.cc:144:32: error: type 'antlr4::tree::TerminalNode *' cannot be narrowed to 'bool' in initializer list [-Wc++11-narrowing]
  ParameterList result{{}, {}, context->VARARGS(), {}};
                               ^~~~~~~~~~~~~~~~~~
../../deps/v8/src/torque/ast-generator.cc:144:32: note: insert an explicit cast to silence this issue
  ParameterList result{{}, {}, context->VARARGS(), {}};
                               ^~~~~~~~~~~~~~~~~~
                               static_cast<bool>()
4 warnings and 2 errors generated.
ninja: build stopped: cannot make progress due to previous errors.
core/lts (v10.x-staging $% u=) %

[addaleax]

@sam-github I’m guessing for this particular issue, you could replace context->VARARGS() with context->VARARGS() != nullptr in the two mentioned locations? But that’s just going off the compiler error.

[sam-github]

@addaleax The errors are in v8, and we don't modify our v8 dep (do we?) unless the change has already landed upstream, so we can't directly modify the C++ code to fix the problem.

I don't even know if I could submit patches to v8 which would eventually be cherry-pickable back to node, because this is v8 6.8, and they are up to 8.1 ATM, so might not accept them.

Thus the ping to @nodejs/v8, in the hopes they understand better whether there are specific changes upstream we can cherry pick back to 6.8, and @nodejs/build to see if this is even considered an issue, or more of a "don't do that, it doesn't work".

[addaleax]

@sam-github I don’t think V8 would accept upstream patches for unsupported versions, but I don’t see any issue with modifying the source code directly in that case.

[targos]

We do modify V8 occasionally when we need to and yes, upstream doesn't accept patches for unsupported versions.

V8 stopped using antlr4 and removed ast-generator.cc in v8/v8@ed6b11d, which I would not be very comfortable backporting to v10.x.

+1 to floating a small patch like @addaleax proposed

[richardlau]

Fixed in 89a306b.