ext/intl: Fix argument position for uninitialized calendar arguments

[LamentXU123]

Found when looking at the code base. IntlCalendar::equals(), IntlCalendar::before(), IntlCalendar::after(), and IntlCalendar::isEquivalentTo() currently report the second parameter position used by the procedural API, even when called as methods. That is, the argument position will be error by -1.

  <?php

  $cal = IntlGregorianCalendar::createFromDate(2024, 0, 1);
  $uninit = (new ReflectionClass(IntlGregorianCalendar::class))
      ->newInstanceWithoutConstructor();

  try {
      $cal->equals($uninit);
  } catch (Error $e) {
      echo $e->getMessage(), PHP_EOL;
  }

  try {
      intlcal_equals($cal, $uninit);
  } catch (Error $e) {
      echo $e->getMessage(), PHP_EOL;
  }

Resulted in:

  IntlCalendar::equals(): Argument #2 ($other) is uninitialized
  intlcal_equals(): Argument #2 ($other) is uninitialized

But I expeected:

  IntlCalendar::equals(): Argument #1 ($other) is uninitialized
  intlcal_equals(): Argument #2 ($other) is uninitialized

See https://3v4l.org/tQdYo#v8.4.18

Ah, ideally in the future maybe we can refactor this whole parameter logic.

[devnexen]

can you chewck if there no other cases like this ?

[LamentXU123]

can you chewck if there no other cases like this ?

I am quite sure there are no other similar thing near. But as the whole code base is using the same practice in argument position there may be more similar bugs in different areas...

Ideally, we shouldn't use those logic at the beginning /_ \

[devnexen]

ok ... give it a bit of time ... a bug but not an awful one, I ll come it in the following days.

[LamentXU123]

ok ... give it a bit of time ... a bug but not an awful one, I ll come it in the following days.

I am wondering if I can merge those little fixes myself so it might make thing easier to you. But I don't sure how to get commit right of this repo.

[devnexen]

not entirely up to me (and I would say it might be a bit early for you to get access IMO).