[libcxx-commits] [PATCH] D125019: [libc++] Avoid creating temporaries in unary expressions involving valarray

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue May 31 13:10:44 PDT 2022


ldionne added a comment.

In D125019#3546592 <https://reviews.llvm.org/D125019#3546592>, @hubert.reinterpretcast wrote:

> Wouldn't one be also bitten if they explicitly instantiated an instance of `valarray` with a program-defined type and made the instantiated member functions available as part of their ABI interface?

Yes, although that comment can be made whenever we add `_LIBCPP_HIDE_FROM_ABI` (aka `_LIBCPP_INLINE_VISIBILITY`) to a method, since that causes the method to be excluded from any explicit instantiation. Concretely, explicitly instantiating standard library types is very brittle (some other gotchas are described here <https://quuxplusone.github.io/blog/2021/08/06/dont-explicitly-instantiate-std-templates/>), and fortunately very few people do it. My intuition tells me that the intersection of people using `valarray` with a user-defined type *and* explicitly instantiating it as part of their ABI is probably empty, but I could be wrong.

IMO, it's a better tradeoff to fix this bug (which will bite unsuspecting users doing normal stuff) and potentially break users who use `valarray` in technically-valid-yet-niche ways, than to leave the bug here to preserve other more niche use cases. Especially since the breakage should be at link time for most of these valid-but-niche use cases. If someone disagrees, let's have a discussion, I'm entirely open to reconsidering this.

If there's no additional discussion by EOW, I'll assume that folks are OK with this direction.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125019



More information about the libcxx-commits mailing list