PEAR.WhiteSpace.ObjectOperatorIndent expects wrong indentation when there are multiple chained calls in the same statement

[Daimona]

NOTE: Copied over from squizlabs/PHP_CodeSniffer#3718 with a reduced example and some more information.

Describe the bug

If you have multiple chained calls within the same statement (for example, an array where multiple elements consist of chained method calls), but using different indentation, then the PEAR.WhiteSpace.ObjectOperatorIndent sniff will expect an incorrect amount of indentation.

Code sample

<?php

namespace Example;

function toJson(): array {
    return [
        'brand' => [
            'title' => $item->product()->brand(),
        ],
        'charges' => $item->charges()
            ->toArray(),
    ];
}

Custom ruleset

<?xml version="1.0"?>
<ruleset name="My Custom Standard">
  <rule ref="PEAR.WhiteSpace.ObjectOperatorIndent" />
</ruleset>

To reproduce

Steps to reproduce the behavior:

1. Create a file called test.php with the code sample above
2. Run phpcs test.php
3. See error message displayed

 11 | ERROR | [x] Object operator not indented correctly; expected 16 spaces but found 12
    |       |     (PEAR.WhiteSpace.ObjectOperatorIndent.Incorrect)
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY

Expected behavior

No issue emitted for the above code.

Versions (please complete the following information)

Operating System	Ubuntu 24.04
PHP version	8.3
PHP_CodeSniffer version	master
Standard	custom
Install type	composer

Additional context

The sniff does:

PHP_CodeSniffer/src/Standards/PEAR/Sniffs/WhiteSpace/ObjectOperatorIndentSniff.php

Lines 76 to 77 in 368817d

	$end = $phpcsFile->findEndOfStatement($stackPtr);
	$next = $phpcsFile->findNext($this->targets, ($stackPtr + 1), $end);

But the whole array literal in the above example is just one statement. So, when analyzing the chained calls at line 8, $next will find the chained calls at line 10-11 and expect them to be indented like the ones at line 8.

Please confirm

• I have searched the issue list and am not opening a duplicate issue.
• I have read the Contribution Guidelines and this is not a support question.
• I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards.
• I have verified the issue still exists in the master branch of PHP_CodeSniffer.

[rodrigoprimo]

Thanks for copying this issue from the old repository, @Daimona. Also, thanks to @lucassabreu for the original report.

I was able to reproduce it. Here is a simplified code snippet that produces the same bug:

$array = [
    [
        $item->first()->second(),
    ],
    $item->first()
        ->second(),
];

But the whole array literal in the above example is just one statement. So, when analyzing the chained calls at line 8, $next will find the chained calls at line 10-11 and expect them to be indented like the ones at line 8.

I believe the problem is actually in another part of the code. The call to File::findEndOfStatement() correctly identifies the comma as the end of the statement and assigns its position to $end. $end is used to limit the scope of the search performed by File::fileNext(), and thus it does not include the chained calls on lines 10-11.

Below, the sniff loops over all the object operators in a given chained call using a while loop:

PHP_CodeSniffer/src/Standards/PEAR/Sniffs/WhiteSpace/ObjectOperatorIndentSniff.php

Line 118 in 368817d

while ($next !== false) {

Here is the code where $next is reassigned to the next object operator:

PHP_CodeSniffer/src/Standards/PEAR/Sniffs/WhiteSpace/ObjectOperatorIndentSniff.php

Lines 191 to 198 in 368817d

	$next = $phpcsFile->findNext(
	$this->targets,
	($next + 1),
	null,
	false,
	null,
	true
	);

I believe the problem is that the sniff is relying on the $local parameter of findNext() to limit the scope of the search, and $local only considers a semicolon as the end of a statement:

PHP_CodeSniffer/src/Files/File.php

Lines 2422 to 2424 in 2e9da03

	if ($local === true && $this->tokens[$i]['code'] === T_SEMICOLON) {
	break;
	}

Different chained calls are not necessarily separated by a semicolon (as in the example that was provided). This means that the sniff currently considers the object operators on the second chained method call as part of the first chained method call and checks their indentation using the indentation of the first element on the first chained call as its base.

Unless I'm missing something, this is a relatively easy fix to make, and I will prepare a PR for it.