Squiz/FunctionSpacing: bug fix - prevent fixer conflict with itself

[jrfnl]

Description

The Squiz.WhiteSpace.FunctionSpacing sniff demands # lines above and below a function declaration, but when determining the number of lines above or below, it does not care for additional code on the same line as the function declaration. I.e.: it does not demand that a function declaration starts on its own line or that the close brace is on its own line (there are other sniffs for that).

The sniff also tries to prevent "double" errors for the same issue, i.e. when two functions are each on their own line without blank lines between them, the sniff will only throw one error for "spacing after" the first function and will not throw an error for "spacing before" for the second function.

To determine whether the "spacing before" error needs to be hidden, the sniff tries to check whether the tokens on the previous line indicate the line contains a function declaration.

As things were, however, this check could bow out too early as it stopped at a scope opener for a wrapping construct (class), however, that wrapping construct could be declared on the same line as the function, which means that in that case, the sniff would not determine the $foundLines correctly, as it stops on the current line at the scope opener instead of on a non-blank line above the function line.

This commit fixes this bug by changing the $stopAt value to contain the wrapping scope opener applicable to the code before the function line. This allows the $foundLines to be determined correctly and prevents the fixer conflict.

Includes additional tests.

Suggested changelog entry

Fixed bug #3904 : Squiz/FunctionSpacing: prevent potential fixer conflict

Related issues/external references

Fixes #3904

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
  • [ ] This change is only breaking for integrators, not for external standards or end-users.
• [ ] Documentation improvement

[jrfnl]

Closing as replaced by https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/93

[jrfnl]

FYI: this fix is included in today's PHP_CodeSniffer 3.8.0 release.

As per #3932, development on PHP_CodeSniffer will continue in the PHPCSStandards/PHP_CodeSniffer repository. If you want to stay informed, you may want to start "watching" that repo (or watching releases from that repo).