Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/nlohmann/json.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. Oct 08, 2024
  2. Sep 05, 2024
    • Griffin Myers's avatar
      Update natvis to reflect 3.11.3 and the current structure of basic_json (#4451) · b36f4c47
      Griffin Myers authored
      * Update natvis Jinja template to reflect the current structure of basic_json.
      
      In 5a1a57510a330a521d1b20170b8e45aad52d790a 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.
      b36f4c47
  3. Jul 07, 2024
  4. Apr 13, 2024
  5. Apr 12, 2024
  6. Apr 10, 2024
  7. Apr 08, 2024
  8. Mar 15, 2024
  9. Jan 28, 2024
  10. Jan 18, 2024
  11. Dec 14, 2023
    • Juan Carlos Arevalo Baeza's avatar
      Fix `to_json` for enums when the enum has an unsigned underlying type. (#4237) · a259ecc5
      Juan Carlos Arevalo Baeza authored
      
      * 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: default avatarJuan Carlos Arevalo Baeza (JCAB) <jcab@ntdev.microsoft.com>
      a259ecc5
  12. Dec 06, 2023
  13. Nov 28, 2023
  14. Nov 27, 2023
  15. Nov 26, 2023
  16. Nov 25, 2023
  17. Nov 01, 2023
  18. Oct 31, 2023
  19. Oct 21, 2023
  20. Oct 04, 2023
  21. Oct 02, 2023
  22. Sep 25, 2023
    • Craig Scott's avatar
      Accept NEW CMake policies up to CMake 3.14 (#4112) · fac07e22
      Craig Scott authored
      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.
      fac07e22
  23. Sep 24, 2023
  24. Sep 23, 2023
  25. Sep 14, 2023
  26. Sep 10, 2023
Loading