[libcxx-commits] [PATCH] D118748: [libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Feb 2 07:46:12 PST 2022


ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

LGTM, please ship this and then cherry-pick it onto `release/14.x`:

  git checkout release/14.x
  git cherry-pick -x <SHA>
  git push



================
Comment at: libcxx/include/ranges:242
 
-#if _LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)
+#if !defined(_LIBCPP_HAS_NO_CONCEPTS)
 
----------------
Quuxplusone wrote:
> jloser wrote:
> > No action required, but this seems like a weird guard for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`. I would have expected the macro used to be something about ranges...
> Huh, good point. I have no idea... oh wait, yes I do. 😛 I bet that every single detail header that involves a view type is guarded by `!defined(_LIBCPP_HAS_NO_CONCEPTS)`, because the view types all require some concept or other. Therefore, when `_LIBCPP_HAS_NO_CONCEPTS`, all of those headers sublimate away, which means nobody ever gets around to defining `namespace views { ... }`, which means line 244 failed to compile, and nobody ever looked into it. 😛We could certainly fix this via
> ```
> namespace ranges::views { }
> namespace views = ranges::views;
> ```
> but I'm not sure I care enough.
I think guarding this is correct. That way, when we move to `_LIBCPP_STD_VER > 17`, this will be guarded the way we want it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118748/new/

https://reviews.llvm.org/D118748



More information about the libcxx-commits mailing list