tree 78474fca4a36b8e6933681e9182c698043acae5a
parent e0edc7ec328e6775e081c30b42837eb84ff282a4
author Maciej Żenczykowski <maze@google.com> 1587752103 -0700
committer Maciej Żenczykowski <maze@google.com> 1587752886 -0700

expected.h - fix bugprone-forwarding-reference-overload warnings

Fixes:
  system/core/base/include/android-base/expected.h:
  186:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
  195:22: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
  611:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]

To quote Tom Cherry:
  I'm a bit confused at what's happening there.
  I think it's a bug in the linter itself.
  The general solution to that problem is a heavy dose of std::enable_if<>
  to hide that constructor when the 'U' parameter is the same class,
  but those constructors do have the necessarily std::enable_if<> lines.

  I think the problem is that the linter doesn't check that the macro
  _ENABLE_IF() expands into std::enable_if<>.  Let me try explicitly
  putting the std::enable_if<> instead of the macro and check if it
  goes away.

  I expanded the macro but the linter doesn't still doesn't accept
  the format of `std::enable_if_t<(condition_here)>* = nullptr`.
  It does accept `typename Enable = std::enable_if_t<(condition_here), void>`,
  which is the syntax used on their example here:
    https://clang.llvm.org/extra/clang-tidy/checks/bugprone-forwarding-reference-overload.html.

  That latter syntax doesn't work for us.
  See the Notes section on
    https://en.cppreference.com/w/cpp/types/enable_if
  as a reference for why what we're doing is correct.

Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I493ff19208cc104f5f176a36ec23fbcb914388f7