[Bug,default/29679] New: C++20 compilation failure - ambiguous comparisons

  https://sourceware.org/bugzilla/show_bug.cgi?id=29679

            Bug ID: 29679
           Summary: C++20 compilation failure - ambiguous comparisons
           Product: libabigail
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: gprocida at google dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

This was reported internally, along with a proposed fix.

To reproduce, change the C++ standard in configure.ac from 11 and 20,
reconfigure and rebuild.

With GCC:

  CXX      abg-dwarf-reader.lo
../../src/abg-dwarf-reader.cc: In function ?bool
abigail::dwarf_reader::op_is_control_flow(Dwarf_Op*, size_t, size_t, size_t&,
dwarf_expr_eval_context&)?:
../../src/abg-dwarf-reader.cc:9007:16: error: ambiguous overload for
?operator!=? (operand types are ?abigail::dwarf_reader::expr_result? and ?int?)
 9007 |       if (val1 != 0)
      |           ~~~~ ^~ ~
      |           |       |
      |           |       int
      |           abigail::dwarf_reader::expr_result
../../src/abg-dwarf-reader.cc:1735:3: note: candidate: ?bool
abigail::dwarf_reader::expr_result::operator==(const
abigail::dwarf_reader::expr_result&) const? (rewritten)
 1735 |   operator==(const expr_result& o) const
      |   ^~~~~~~~
../../src/abg-dwarf-reader.cc:9007:16: note: candidate: ?operator!=(int64_t
{aka long int}, int)? (built-in)
 9007 |       if (val1 != 0)
      |           ~~~~~^~~~

With Clang there are several more errors, but they are explained by:
https://github.com/llvm/llvm-project/issues/57711

The fix that was proposed internally was:

And the accompanying explanation was:

1. operator==(const expr_result&, const expr_result&) is ambiguous because
C++20 could call this with args (val1, 0) or with reversed args (0, val1).
This is because of implicit conversion from int to expr_result.
Adding operator!= disables argument reversal and resolves the ambiguity.

2. 0 == val1 is then illegal because the LHS (int) does not provide operator==.
When argument reversal is disabled, the LHS should provide operator==.
(Same for !=).

I'll be honest and say that I haven't followed the details of this.
However, another way to resolve the issue might be to eliminate the
implicit conversion - these tend to be sources of other surprises
anyway.

Regards,
Giuliano.
  

https://sourceware.org/bugzilla/show_bug.cgi?id=29679

--- Comment #1 from gprocida at google dot com ---
This was resolved with:

https://sourceware.org/git/?p=libabigail.git;a=commit;h=e6beace1094a789187dbd1e4ae4d674e9f0933c6