* 🚧 conversions for std::optional
* 🏁 fix <optional> inclusion
* 💚 overwork tests
* Use JSON_HAS_CPP_17 only after it has been defined
* ✅ update tests
* 🏁 include right <optional> header
* ♻️ do not include experimental headers
* Add missing #endif after rebase
* Fix failing test
* Only define conversion to std::optional when JSON_USE_IMPLICIT_CONVERSION is disabled.
* missing endif
* Remove Wfloat-equal suppress
* amalgamate
* Move include of optional out of macro_scope; probably does not make sense to be there
* Make clang-tidy happy
* Suppress lint instead of changing to 'contains'
---------
Co-authored-by: Niels Lohmann <mail@nlohmann.me>
Co-authored-by: Markus Palonen <markus.palonen@gmail.com>
* Update natvis Jinja template to reflect the current structure of basic_json.
In 5a1a57510a the underlying structure of
basic_json was altered to move m_type and m_value under an m_data field.
This updates the nativ template to be consistent with this change.
* Generate nlohmann_json.natvis for 3.11.3 and latest basic_json structure.
* Enhance the UDT unit test to expose the issue
Add a new enum type with uint64_t as the underlying type.
Use it in the overall UDT. Not strictly needed, but it helps exercise its expected usage.
Create an object of this enum type with a large value (negative if cast to int64_t).
Perform several checks on this object as converted to `json`, which fail without the fix.
* Fix the issue in the relevant `to_json` overload.
Select the correct json type depending on the signedness of the enum's underlying type.
This fixes the new checks in the unit test.
* Add the fix to the single_include
I ran `make pretty` but that modified 20 files, performing a significant amount of indentation changes, none of them related to my change.
I ran `make amalgamate`, but that did nothing. Apparently, the make rule won't run if the single_include files have already been updated by `make pretty`.
I forced `make amalgamate` to do the work by touching the file with the fix.
I then decided to keep just the minimal needed change: the addition of the fix to the single_include file.
I just am not conversant enough in Linux to know whether I installed astyle correctly (had to clone the source from a beta branch and build, in order to get support for `--squeeze-lines`).
* Resolve CI errors and use qualified `std::uint64_t`
The fix was relying on implicit conversions in the non-taken branch.
- Ordinarily (work on a C++20 codebase) I would have used `if constexpr` here, sidestepping the issue, but that's not available on C++11 so I didn't bother.
- So instead of an `if` statement, I used a compile-time constant to select the correct overload.
- This is arguably better in this case, anyway.
I was using function-style casts for typed constants, which I consider superior for constants, but the CI checks disagree, so changed all to `static_cast`.
- For some reason, the CI checks didn't point at all of them, so I hope I caught them all myself.
Built with clang14 and all unit tests pass.
---------
Co-authored-by: Juan Carlos Arevalo Baeza (JCAB) <jcab@ntdev.microsoft.com>
Starting with CMake 3.27, deprecation warnings are issued
when asking for policy settings for CMake 3.4 or earlier.
The cmake_minimum_required() command accepts a version
range, which allows NEW policy settings up to the upper end
of that range to be used, but without raising the minimum
CMake version above the bottom of that range. This means
NEW policy settings will be used where available, without
requiring them. This change updates the project's
cmake_minimum_required() calls to use a version range to
extend the upper policy version to 3.14 where it wasn't already
at that version or higher. This prevents the deprecation warning
from CMake 3.27, and gives breathing space before a future
CMake release will start issuing similar deprecation warnings
again.
