[SERVER-47912] add MONGO_CONCEPTS_ macro prefix Created: 03/May/20  Updated: 06/Dec/22  Resolved: 23/Jun/20

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

Type: Improvement Priority: Major - P3
Reporter: Billy Donahue Assignee: Backlog - Service Architecture
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-48898 Remove/update util/concepts.h macros ... Closed
Assigned Teams:
Service Arch
Participants:

 Description   

The src/mongo/util/concepts.h header defines a set of 4 macros:

#define TEMPLATE(...)
#define REQUIRES(...)
#define REQUIRES_OUT_OF_LINE_DEF(...)
#define REQUIRES_FOR_NON_TEMPLATE(...)

Change these to

#define MONGO_CONCEPTS_TEMPLATE(...)
#define MONGO_CONCEPTS_REQUIRES(...)
#define MONGO_CONCEPTS_REQUIRES_OUT_OF_LINE_DEF(...)
#define MONGO_CONCEPTS_REQUIRES_FOR_NON_TEMPLATE(...)

An examination of the sites that use these names shows they can afford the extra space.

TEMPLATE and REQUIRES are single common words that are overloaded to mean various unrelated things. Google uses REQUIRES annotations to enforce lock ordering, and even has its own #define REQUIRES in the vendored benchmark library, which I'm in the process of upgrading. It would be clearer and safer if Mongo's Concepts macros were renamed with a MONGO_CONCEPTS_* prefix.

I thought of this when I saw that the Catch framework uses a REQUIRE macro, which is almost but not quite a collision with our REQUIRES macro. It's a close call. In Catch (which has been tossed around as a possibility for us SERVER-37517), you can #define CATCH_CONFIG_PREFIX_ALL to avoid such conflicts, so their REQUIRE becomes CATCH_REQUIRE instead.



 Comments   
Comment by Billy Donahue [ 17/Jun/20 ]

Fine by me!

Comment by Mira Carey [ 16/Jun/20 ]

I've filed SERVER-48898 to revisit these macros on the other side of c++20. Any objections to closing this as wontfix in the short term?

Comment by Ratika Gandhi [ 16/Jun/20 ]

billy.donahue any objections to closing this ticket?

Comment by Mira Carey [ 16/Jun/20 ]

My take on this one is that these macros solve a transitional problem (specifically a lack of concepts support in our toolchain). Once we get to C++20, we won't need these (at least TEMPLATE/REQUIRES).

We also don't make a special effort to enforce macro hygiene in general, for better or worse.

If we don't have a pressing need for this now, I'd like to close this out and expect that we'll be able to dump the majority of these macros as part of converting to C++20

Comment by Billy Donahue [ 03/May/20 ]

CR http://mongodbcr.appspot.com/603950001

Generated at Thu Feb 08 05:15:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.