fix(tests): read cbor byte view via std::span, not basic_string_view<std::byte>#691
fix(tests): read cbor byte view via std::span, not basic_string_view<std::byte>#691aruisdante wants to merge 1 commit into
Conversation
…byte>
libc++ shipped with Xcode 26.5 (the current macos-latest runner image)
deprecates std::char_traits<T> for T outside {char, wchar_t, char8_t,
char16_t, char32_t}. std::basic_string_view<std::byte> instantiates the
now-deprecated std::char_traits<std::byte>, and tests build with -Werror,
so tests/cbor/test_read_byte_containers.cpp fails to compile on
macos-latest (the only matrix cell that both compiles the tests and uses
the new libc++).
Switch the byte view to std::span<const std::byte>. It is the idiomatic
non-owning byte view, does not depend on char_traits at all, and
satisfies the same rfl::concepts::ContiguousByteContainer that
rfl::cbor::read requires — so the test exercises the identical read
overload. The sibling std::uint8_t-array test is unchanged.
This library specialization is slated for removal, not just deprecation,
so migrating off it is the durable fix rather than suppressing the
warning.
There was a problem hiding this comment.
Code Review
This pull request updates tests/cbor/test_read_byte_containers.cpp to replace the use of std::basic_string_view<std::byte> with std::span<const std::byte>. This change avoids compilation errors under -Werror on newer toolchains like libc++ (Xcode 26.5+), which deprecates std::char_traits<std::byte>. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
@aruisdante sorry, it took me quite a while to notice your PR |
Problem
macos-latest (tests)is red on current CI (and will fail onmainthe next time that job runs —mainis green only because its last macOS run predates the runner-image bump). The failure is in an unrelated test, not in whatever PR happens to trigger the run:GitHub moved the
macos-latestimage to macOS 15 + Xcode 26.5, whose libc++ now marksstd::char_traits<T>deprecated for anyToutside{char, wchar_t, char8_t, char16_t, char32_t}.std::basic_string_view<std::byte>instantiates the now-deprecatedstd::char_traits<std::byte>, and the test suite builds with-Werror(tests/CMakeLists.txt), so the deprecation is a hard error.It only shows up in one matrix cell because that cell is the sole intersection of "new libc++" and "compiles the tests":
macos-15-intelstill runs an older toolchain, and thebenchmarkscells never compile the test files.Change
Read the CBOR bytes through
std::span<const std::byte>instead ofstd::basic_string_view<std::byte>.std::spanis the idiomatic non-owning byte view, does not depend onchar_traitsat all, and satisfies the samerfl::concepts::ContiguousByteContainerthatrfl::cbor::readrequires (std::byteis byte-like;ByteSpanLike's own doc-comment names span views as intended input) — so the test exercises the identicalreadoverload. The siblingstd::uint8_t-array test is unchanged.The libc++ specialization is slated for removal, not just deprecation, so migrating off it is the durable fix rather than suppressing the warning with a diagnostic pragma.
Testing
Verified with Apple clang 21 on macOS 26.5 (same libc++ that ships the deprecation), using the exact CI flags (
-std=gnu++20 -Wall -Werror -Wdeprecated-declarations):basic_string_view<std::byte>reproduces the error.std::span<const std::byte>compiles clean andstatic_asserts green against the realrfl::concepts::ContiguousByteContainer/ByteSpanLikefrominclude/rfl/concepts.hpp.Note
Independent of, and complementary to, #688 (a C++26 clang crash workaround touching only
StringLiteral.hpp); that PR's red macOS cell is this same pre-existing toolchain regression, not anything in its diff.Disclosure: this investigation and patch were produced with the assistance of an AI coding agent (Claude Code / Claude Opus), reviewed by me before submitting.