Details
-
Task
-
Resolution: Done
-
P2: Important
-
None
-
None
-
C++20
-
2
-
c4bddc4765 (qt/qtdeclarative/dev) b5924c14d6 (qt/qtdeclarative/6.4) b5924c14d6 (qt/tqtc-qtdeclarative/6.4) ee8c32c7d5 (qt/qtdeclarative/6.3) ee8c32c7d5 (qt/tqtc-qtdeclarative/6.3) 63d78523a9 (qt/tqtc-qtdeclarative/5.15) ee8c32c7d5 (qt/qtdeclarative/6.3.2)
-
Team B Foundation Sprint 60, Foundation Sprint 61
Description
About the only warning left in a GCC 11 or Clang 10 C++20 build of Qt declarative is this:
n file included from qt5/qtdeclarative/src/qml/../3rdparty/masm/assembler/MacroAssemblerX86Common.h:31,
from qtdeclarative/src/qml/../3rdparty/masm/assembler/MacroAssemblerX86_64.h:31,
from qtdeclarative/src/qml/../3rdparty/masm/assembler/MacroAssembler.h:53,
from qtdeclarative/src/qml/jit/qv4assemblercommon_p.h:59,
from qtdeclarative/src/qml/jit/qv4assemblercommon.cpp:45:
qtdeclarative/src/qml/../3rdparty/masm/assembler/X86Assembler.h: In member function ‘JSC::X86Assembler::TwoByteOpcodeID JSC::X86Assembler::jccRel32(Condition)’:
qtdeclarative/src/qml/../3rdparty/masm/assembler/X86Assembler.h:205:48: warning: arithmetic between different enumeration types ‘JSC::X86Assembler::TwoByteOpcodeID’ and ‘JSC::X86Assembler::Condition’ is deprecated [-Wdeprecated-enum-enum-conversion]
205 | return (TwoByteOpcodeID)(OP2_JCC_rel32 + cond);
| ~~~~~~~~~~~~~~^~~~~~
qtdeclarative/src/qml/../3rdparty/masm/assembler/X86Assembler.h: In member function ‘JSC::X86Assembler::TwoByteOpcodeID JSC::X86Assembler::setccOpcode(Condition)’:
qtdeclarative/src/qml/../3rdparty/masm/assembler/X86Assembler.h:210:43: warning: arithmetic between different enumeration types ‘JSC::X86Assembler::TwoByteOpcodeID’ and ‘JSC::X86Assembler::Condition’ is deprecated [-Wdeprecated-enum-enum-conversion]
210 | return (TwoByteOpcodeID)(OP_SETCC + cond);
| ~~~~~~~~~^~~~~~
Since it's 3rd-party code, we need to decide how we deal with this. It's about the only case of -Wdeprecated-enum-enum left in Qt, so prevents us from removing the -Wnoerror for it again.
Options, afaics:
- suppress the warning at the cmake level for the masm sub-project
- if we include the header from one of our own TUs (IIRC we do), we can slap QT_WARNING_DISABLE around the #include
- fix the warning at the source code level
- might be a convoluted change
- should then upstream the fix