Fix #4041: Support zero-member types in NLOHMANN_DEFINE_TYPE_* macros#5142
Fix #4041: Support zero-member types in NLOHMANN_DEFINE_TYPE_* macros#5142suchetindrakanty wants to merge 1 commit into
Conversation
|
I suppose this can co-exist with #5099 in that users of older standards need to use the specialized macros, and users of the newer standards can use the current macros. |
🔴 Amalgamation check failed! 🔴The source code has not been amalgamated. @suchetindrakanty |
|
This pull request has been marked as stale because it has had no activity for 30 days. While we won’t close it automatically, we encourage you to update or comment if it is still relevant. Keeping pull requests active and up-to-date helps us review and merge changes more efficiently. Thank you for your contributions! |
nlohmann
left a comment
There was a problem hiding this comment.
__VA_OPT__ is a C++20 preprocessor feature (roughly GCC 8+/Clang 12+), used here completely unconditionally with no #if defined(JSON_HAS_CPP_20) or compiler-version check — despite the file already having an established pattern for exactly this (see the filesystem feature-detection guard a few lines above). Since README.md documents support for GCC 4.8–14.2 and Clang 3.4–21.0, and the project's own CI (ci_test_compilers_gcc_old: 4.8/4.9/5/6, ci_test_compilers_clang: 3.4–11) actually builds on those toolchains, every existing non-empty-member use of these 12 macros — not just the new zero-member case — will fail to compile with an "undeclared identifier __VA_OPT__" error on those compilers. The new comment claiming "there is no regression" is only true for the previously-broken zero-member path; it's false for the common, non-empty-member path this PR puts at risk.
Fixes #4041
This PR addresses an issue where NLOHMANN_DEFINE_TYPE_* macros fail when used with zero members.
Problem
When VA_ARGS is empty, macro expansion generates invalid code, causing compilation errors.
Solution
Testing