qvariant.h:710: warning: C4702: unreachable code

Robert Hairgrove

I'm sorry, but this warning is still there even after I applied the latest MSVC update. 😠

It does not appear when building with Qt 6.5.3, but it appears with Qt 6.7.3 and (presumably) all later versions up to and including 6.11.0 beta. However, the line numbers of qvariant.h are different; but the code appears to be exactly the same.

Once again, this is with std:c++17.

And with GCC 13.3.0 on Linux, there never was any error. I think the code in qvariant.h is probably correct, and MSVC is wrong.

Robert Hairgrove

Can we close this now? Ich habe wirklich keine Lust mehr...

Christian Ehrlicher

You can close this since you're too lazy to add one line in the Qt header for a fix...

Robert Hairgrove

TO THE QT MODERATORS:

What do you think of one user calling another "stupid" or "lazy", even if that user is a "LIFETIME QT CHAMPION"?

Ad hominem abuse should not be tolerated in a professional forum.

Can you please block this person from replying to any of my topics (forever)?

Robert Hairgrove

@Robert-Hairgrove Apparently, the person I would like to block is one of the moderators, so I cannot block him/her/it...

In the future, i will abstain from engaging in any interactions with this user.

I hope that that person does the same.

Axel Spoerl

Hi @Robert-Hairgrove,

looking at the technical aspect of this long topic, the warning is a false positive of MSVC. Our code is written work on multiple platforms with multiple compilers. It's a known issue that C4702 comes up here and there and it's completely harmless.
The compiler evaluates that either the if or one of the else if branches are reached. Therefore the last line won't. The code is still valid and intentional. That's why gcc doesn't complain. Even if the warning is silenced at some MSVC version after v18.2.1, it might still return.

The exact constellation of QVariant and the types involved matters. That's where the problem of this topic starts. The actual compiler warning is triggered when a template within our framework is used and compiled by your application. This topic doesn't contain a minimal compilable example that reproduces the issue. Providing such an example would have put us in the position to reproduce the problem and test potential fixes.
It's our intention to avoid such warnings to the extent possible. That's why @Christian-Ehrlicher has asked you to try a patch to Qt. Since you are the only one of us who can safely reproduce the warning message, you are the only one you can safely test a fix or workaround.

It's also fine, if that's not worth your while. OTOH, it's no "hacking around". It's pretty standard. It's part of a collaborative attempt to isolate and fix a minor, harmless, but annoying issue.

I think that's the point when communication went a sideways.
Bringing up an issue and refusing to co-operate at some point can be disappointing.
If you felt insulted by the terms "stupid" or "lazy", I do understand.
Please accept my apologies on behalf of the Qt Forum community.

Looking at the solution side of things: We are stuck. Compiling Qt (qtdeclarative and all submodules pulled in) doesn't throw C4702 for me. Probably the internal use of QVariant doesn't render that last line unreachable. If you want it solved (if possible at all), please post a minimal compilable example or try @Christian-Ehrlicher's fix. If you want to live with a false positive warning, the topic can be closed.

Cheers
Axel

Robert Hairgrove

@Axel-Spoerl said in qvariant.h:710: warning: C4702: unreachable code:

If you felt insulted by the terms "stupid" or "lazy", I do understand. Please accept my apologies on behalf of the Qt Forum community.

Thank you. I really appreciate your apology.

looking at the technical aspect of this long topic, the warning is a false positive of MSVC. Our code is written work on multiple platforms with multiple compilers. It's a known issue that C4702 comes up here and there and it's completely harmless.

That's exactly what I thought, and that is why I did not want to start changing any of Qt source code. I don't have nearly the resources to test such things under all combinations of versions, compilers, etc. And if the developers of Qt are of the opinion that this is valid code, then who am I to argue with that? My initial goal was to silence the warning since I also didn't get any warning from GCC nor from Clang here.

However, I found these discussions in the meantime:

https://stackoverflow.com/questions/51398356/compiler-tries-to-evaluate-unreachable-code-after-constexpr-if
https://developercommunity.visualstudio.com/t/Early-return-with-if-constexpr-raises/10346431

The first exchange in StackOverflow points out that, according to how if constexpr works, any time one of the if ... else branches evaluates to true, the next return statement outside of the last block will be seen as unreachable code. It is only reachable if ALL of the if ... else branches evaluate to false. In light of this, it seems that the proposed fix would be a possible solution.

The second exchange on the Microsoft site indicates that the warning is intentional, and it is by design that this warning is issued.

It's our intention to avoid such warnings to the extent possible. That's why @Christian-Ehrlicher has asked you to try a patch to Qt. Since you are the only one of us who can safely reproduce the warning message, you are the only one you can safely test a fix or workaround.

This warning has been around since Qt 6.6.0, or whenever the if constexpr construct was introduced into the QVariant code. It has been noticed by others, and I really do not think it is "up to me" now to look into fixing this. Perhaps nobody is interested in fixing MSVC warnings, anyway? There are certainly plenty of others that need fixing, IMHO...

If you want to live with a false positive warning, the topic can be closed.

Agreed.

Axel Spoerl

@Robert-Hairgrove said in qvariant.h:710: warning: C4702: unreachable code:

This warning has been around since Qt 6.6.0, or whenever the if constexpr construct was introduced into the QVariant code. It has been noticed by others,

This statement is not correct. The constexpr construction hasn't introduced anything and certainly not an issue. It's an optimisation, because it ensures the evaluation is made at compile time. The warning is a false positive: if constexpr in a template function can lead to unreachable code for one type but not for another.

and I really do not think it is "up to me" now to look into fixing this.

The question to you was not to fix anything, it was to try a possible fix.

Perhaps nobody is interested in fixing MSVC warnings, anyway? There are certainly plenty of others that need fixing, IMHO...

As said before, compiling Qt doesn't throw such warnings. If your application does and you want help from this forum, please provide a minimal compilable example or participate in troubleshooting. If any of that is beyond acceptable involvement for you, this forum won't be able to help you.

Please mark the issue solved.

Robert Hairgrove

@Axel-Spoerl said in qvariant.h:710: warning: C4702: unreachable code:

Please mark the issue solved.

I already marked it solved a couple of days ago.

Anyway, here is my minimal test app:
qmake project file:

# FILE: test_variant_warning.pro
QT = core
CONFIG += c++17 cmdline warn_on
SOURCES += main.cpp
msvc {
QMAKE_CFLAGS_WARN_ON ~= s/-W3/-W4
QMAKE_CXXFLAGS_WARN_ON ~= s/-W3/-W4
}

Source file:

// main.cpp
#include <QCoreApplication>
#include <QVariant>
#include <iostream>

// Set this to 1 to enable the warning C4702:
#define MY_TEST 0

int main(int argc, char *argv[])
{
  QCoreApplication a(argc, argv);
  Q_UNUSED(a);

  QString h = "Hello world";

#if MY_TEST
  QVariant s = h;
  QVariant v = QVariant::fromValue(s);
  if (!std::is_same_v<decltype(s), QVariant>) {
#else
  QVariant v = QVariant::fromValue(h);
  if (!std::is_same_v<decltype(h), QVariant>) {
#endif
    std::cout << "QVariant v constructed directly from type " << v.metaType().name() << std::endl;
  } else {
    std::cout << "QVariant v constructed from QVariant of type " << v.metaType().name() << std::endl;
  }
  return 0;
}

Build with MSVC 2022 (latest version) or MSVC 2026 with c++17 and warning level set to /W4 (see project file ... this is already set up there).

And I did edit qvariant.h to try out the fix, which involves inserting else at the beginning of line 710 in the 6.10.2 sources. It does seem to suppress this warning.

Robert Hairgrove

@Axel-Spoerl said in qvariant.h:710: warning: C4702: unreachable code:

@Robert-Hairgrove said in qvariant.h:710: warning: C4702: unreachable code:

This warning has been around since Qt 6.6.0, or whenever the if constexpr construct was introduced into the QVariant code. It has been noticed by others,

This statement is not correct.

And what about https://qt-project.atlassian.net/browse/QTBUG-141934 ?

The constexpr construction hasn't introduced anything and certainly not an issue. It's an optimisation, because it ensures the evaluation is made at compile time. The warning is a false positive: if constexpr in a template function can lead to unreachable code for one type but not for another.

Perhaps nobody is interested in fixing MSVC warnings, anyway? There are certainly plenty of others that need fixing, IMHO...

As said before, compiling Qt doesn't throw such warnings. If your application does and you want help from this forum, please provide a minimal compilable example or participate in troubleshooting. If any of that is beyond acceptable involvement for you, this forum won't be able to help you.

Looks like nobody is going to fix any of the /W4 level warnings, anyway (see remarks in the previously linked bug report by Thiago Maceira). Originally, he was going to insert the else, but then pulled back because this change would "break GCC". How is that possible, since GCC has ignored the -Wunreachable-code warning for many years now (since 2015, I believe)?.