Granted, MSVC hides these being the /permissive- compiler flag. We compile our projects with msvc, and we use the corresponding flag to get the conformant behavior.
The results of this behavior might be something like this:
In my case with a similar structure, the analyzer emits cpp:S1116 Rules explorer and points it at the semicolon, as if there’s an empty statement here. My conclusion based on this is that something about the operator representation isn’t understood like it should.
I realize that the usage of alternative operators relate to this post about the related rule that suggests to not use these operator representations. We have disabled this rule, because we like these operator representations. But I will go further and say that “because developers might be surprised” is not a good reason to emit a warning, at least not by default. That line of thinking is fully compatible with emitting a warning about code doing exactly what it says. I have previously run into such a case from msvc, where this warning is emitted on a function declared with override. In a nutshell, such a warning effectively says “this might surprise you, but the code does exactly what it says it does”.
However, an actual good reason to emit a warning about usage of the alternative operator representations would be due to compatibility concerns, like I alluded to earlier. Which makes for a much better description. And the compatibility concerns are not necessarily isolated to MSVC itself. There is also a compatibility issue in clang-cl as reported in this bug report, which is not even resolved in a released version of LLVM yet.
Another small note about this is that the markdown used in the above snippet correctly highlights or as a keyword.
I can only reproduce the mentioned issue when I’m not including <ciso646>. If I don’t include it then I get a similar warning and even VS Intellisense complains.
If you still face the issue, after including the header, it might be a config issue that we will have to investigate.
I don’t think we disagree, I’m just trying to figure out from your test case what part of the configuration we are getting wrong.
I know that it is according to the standard, but not according to default MSVC. On our side, we are trying to mimic the behavior of MSVC. So if your compiler is accepting it without a header it means that we are getting some configuration wrong.
Anyway, I have enough information to fix the issue now. Feel free to watch the ticket for updates.
It so happens that the MSVC compiler will by default use permissive mode, but the /permissive- minus flag that I mentioned makes it conformant and brings in these from the language side. In permissive mode one would include the <ciso646> header as mentioned, which defines macros for these.
However, our projects have enabled the conformance mode setting in MSBuild, which in turns passes /permissive- to the compiler. While /permissive- is not enabled by default in the compiler, a new Visual Studio project will have conformance mode enabled by default.
Furthermore, when using /std:c++latest or /std:c++20 switches for the language standard, the compiler enables conformance mode by default.
So there are many different kinds of default that one might take into consideration. In an ideal world it would probably have been possible to pick up all the compiler switches from the project files.