[SERVER-29780] MONGO_invariant confuses the MSVC compiler that execution may continue Created: 21/Jun/17  Updated: 27/Oct/23  Resolved: 21/Jun/17

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: 3.5.9
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Kaloian Manassiev Assignee: Mira Carey
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

Compiling this code under MSVC produces the following warning:

[1/2] CXX build\ninja\mongo\db\ops\write_ops_parsers_test.obj
e:\workspace\mongo\src\mongo\db\ops\write_ops_parsers_test.cpp(341) : warning C4715: 'mongo::A0xc872fdd4::`anonymous namespace'::MyMockDBClient::call': not all control paths return a value

The warning disappears if the invariant is changed to MONGO_UNREACHABLE, which probably means that the infinite loop in MONGO_invariant
is confusing the compiler somehow.



 Comments   
Comment by Mira Carey [ 21/Jun/17 ]

This isn't something we can fix on our end. It might go away with a visual studio upgrade, but until then workarounds will have to include useless returns and/or using MONGO_UNREACHABLE in lieu of invariant

Comment by Mira Carey [ 21/Jun/17 ]

Ack nope. Sorry, meant to mark this works as designed, mis-jira'd

Comment by Kaloian Manassiev [ 21/Jun/17 ]

Ah I overlooked the while(false) condition. You changed it to DWS - do you need anything from me?

Comment by Mira Carey [ 21/Jun/17 ]

There's no infinite loop in MONGO_invariant, it's a "do {} while (0)". Which is the standard way to write hygienic macros with the preprocessor

It seems more likely that msvc is incapable of noticing that we always follow the conditional in:

    do {
        if (bool(!(!"call() not implemented"))) {
            ::mongo::invariantFailed("!\"call() not implemented\"", ...);
        }
    } while (false)

I think this one get's chalked up to deficiencies in msvc.

Generated at Thu Feb 08 04:21:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.