[all-commits] [llvm/llvm-project] d4c39f: [libc++] Add workaround to avoid breaking users of...

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d4c39f1ab94abc1dd4fff1e82dd4fa97265940e1
      https://github.com/llvm/llvm-project/commit/d4c39f1ab94abc1dd4fff1e82dd4fa97265940e1
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2022-03-15 (Tue, 15 Mar 2022)

  Changed paths:
    M libcxx/include/span
    A libcxx/test/libcxx/containers/views/span.cons/range.pass.cpp
    A libcxx/test/libcxx/containers/views/span.cons/range.verify.cpp

  Log Message:
  -----------
  [libc++] Add workaround to avoid breaking users of <span> when <ranges> are disabled

Back in 3a208c68942e, we implemented the range-based constructor for <span>.
However, in doing so, we removed a previous non-standard constructor that
we provided before shipping <ranges>. Unfortunately, that breaks code that
was relying on a range-based constructor until we ship all of <ranges>.

This patch reintroduces the old non-conforming constructors and tests
that were removed in 3a208c68942e and uses them whenever <ranges> is
not provided (e.g. in LLVM 14). This is only a temporary workaround
until we enable <ranges> by default in C++20, which should hopefully
happen by LLVM 15.

The goal is to cherry-pick this workaround back to the LLVM 14 release
branch, since I suspect the constructor removal may otherwise cause
breakage out there, like the breakage I saw internally.

We could have avoided this situation by waiting for C++20 to be finalized
before shipping std::span. For example, we could have guarded it with
something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from
accidentally starting to depend on it before it is stable. We did not
have these mechanisms when std::span was first implemented, though.

Differential Revision: https://reviews.llvm.org/D121626