[Bug c++/106520] New: 2+ index expressions in build_op_subscript are incorrectly interpreted as comma expression

["mkretz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106520

            Bug ID: 106520
           Summary: 2+ index expressions in build_op_subscript are
                    incorrectly interpreted as comma expression
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mkretz at gcc dot gnu.org
  Target Milestone: ---

Commit b38c9cf6d570f6c4c1109e00c8b81d82d0f24df3 implemented Multidimensional
subscript operator [PR102611]. However, the backwards compatibility leads to
surprising results. E.g.:

struct A
{
  void operator[](unsigned);
  void operator[](unsigned, unsigned);
};

struct B
{
  explicit operator unsigned() const;
};

void f(A a, B b)
{
  a[1];
  a[b, 2];
}

Compiles to two calls to A::operator[](unsigned) with the following
diagnostics:

<source>: In function 'void f(A, B)':
<source>:15:4: warning: top-level comma expression in array subscript changed
meaning in C++23 [-Wcomma-subscript]
   15 |   a[b, 2];
      |    ^

[https://godbolt.org/z/f6vf3x5Gv]

The user probably intended to call the two-index subscript overload. But
there's no indication why the call failed. The warning is probably puzzling to
most users. It's probably not obvious to most users that the "wrong" function
gets called.

I'm not sure the compatibility issue is worth it. I think it would be better to
call build_op_subscript with unmodified complain and let code that turns on
-std=c++23 break if it relies on comma expressions in subscripts.