Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes in ztd::idk::span broke several runtime test compilation #10

Open
PeterCDMcLean opened this issue Apr 12, 2024 · 0 comments
Open

Comments

@PeterCDMcLean
Copy link

A commit in ztd::idk 🛠 Improve 's ability to handle poor arguments broke several tests in:

  • tests/run_time/source/bit_view.bounds.cpp
    • Both std::deque tests in bounds now fail.
  • tests/run_time/source/bit_view.subrange.cpp
    • All tests (std::list and std::deque) fail in subrange.

When I analyzed the bounds test, it looks like:

// TestType is long unsigned int
// Storage is deque
	using span_range  = ::ztd::span<TestType>;

	using R           = std::conditional_t<std::is_constructible_v<span_range, Storage&>, span_range,
          std::conditional_t<std::is_const_v<TestType>, c_sub_range, sub_range>>;

R being ::ztd::span

bit_view constructor attempts to construct the ::ztd::span with the std::deque in __base_t(std::move(__extents))

		template<typename... _Args>
		constexpr bit_view(bounds_type __extents, _Args&&... __args) noexcept(
		     ::std::is_nothrow_constructible_v<container_type,
		          _Args...>&& ::std::is_nothrow_move_constructible_v<bounds_type>)
		: __base_t(std::move(__extents)), _M_storage(::std::forward<_Args>(__args)...)
		{
		}

and the ztd::span cannot match the 3-arg constructor used at:

			template <typename _Range,
			     ::std::enable_if_t<!::ztd::is_std_or_c_array_v<::ztd::remove_cvref_t<_Range>> // cf
			          && !::ztd::is_initializer_list_v<::ztd::remove_cvref_t<_Range>>          // cf
			          && !::ztd::__span_detail::__is_span_v<::ztd::remove_cvref_t<_Range>>     // cf
			          >* = nullptr>
			ZTD_EXPLICIT(extent != ::ztd::__span_detail::__dynamic_extent)
			constexpr span(_Range&& __range) noexcept : span(__rng_key, __rng_key, ::std::forward<_Range>(__range)) {
			}

Likely due to the large template condition failing one of the checks from

			template <typename _Range,
			     ::std::enable_if_t<
			          ::ztd::ranges::is_range_v<_Range>                                                        // cf
			               && ::ztd::ranges::is_range_contiguous_range_v<_Range>                               // cf
			                    && ::ztd::ranges::is_sized_range_v<_Range>                                     // cf
			                         && ::ztd::is_non_derived_compatible_pointer_v<                            // cf
			                              ::std::remove_reference_t<::ztd::ranges::range_reference_t<_Range>>, // cf
			                              element_type>                                                        // cf
			          && (::std::is_lvalue_reference_v<_Range>                                                 // cf
			                    ? (::std::is_const_v<::std::remove_reference_t<_Range>>                        // cf
			                              ? (::std::is_const_v<element_type>)
			                              : true)
			                    : (true)) // cf
			          >* = nullptr>
			ZTD_EXPLICIT(extent != ::ztd::__span_detail::__dynamic_extent)
			constexpr span(
			     ::ztd::__span_detail::__rng_key_t, ::ztd::__span_detail::__rng_key_t, _Range&& __range) noexcept
			: __base_span_size(::ztd::ranges::size(__range)), _M_data(::ztd::ranges::data(__range)) {
			}

(These sections of span.implementation.hpp were all updated in the commit I mentioned earlier)

That's as far as I have got on my own. Could you please take a look to see if itsy_bitsy can be updated to be compatible with the new span constructors?

cmake --version
cmake version 3.26.4
g++ --version
g++ (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924

full_compile_error.txt

P.S. apart from some renaming of adl_ranges and these failures, all the other tests pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant