Universal/DisallowAlternativeSyntax: bug fix - handle if/elseif statements in one go #161
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to PR #90 - note: this bug has not been in a tagged release, only in
develop
after #90.As things were, the sniff would examine - and potentially fix - each control structure keyword which could be used with alternative syntax individually.
For potentially multi-part control structures, like
if
-elseif
-else
, this could lead to parse errors in the fixed code as mixing curly braces with alternative syntax within the same control structure "chain" is not allowed.This only comes into play when the
$allowWithInlineHTML
property has been set totrue
as that's the only time when anif
would potentially be treated differently from the associatedelse
(one containing inline HTML being left alone, the other not containing inline HTML being "fixed").While
try
-catch
anddo
-while
are also potentially multi-part control structures, these do not allow for using the alternative control structure syntax, so for the purposes of this sniff,if
-elseif
-else
chains are the only ones we need to take into account.Also take note of the fact that
else if
(with a space between) is not allowed when using alternative syntax, so we don't need to take the keyword potentially being split into account.This commit adjusts the sniff to handle these chains in one go and to prevent the potential parse error, by:
T_ELSEIF
orT_ELSE
tokens. Note: this does affect how the metrics are recorded. Previously a metric would be recorded for each keyword. Now a metric will be recorded only for the first keyword in a chain. This doesn't make a difference for non-chained control structures, but it does make a difference for chainedif/else
sets. Also note: the metric will only be recorded for control structure keywords which support alternative syntax, not for all control structures. This remains the same as before.end*
and remembering each control structure keyword (opener/closer) encountered along the way in case of a chain. For multi-part chains, once an inline HTML token has been encountered, subsequent "leafs" will no longer be examined for inline HTML. This should yield a small performance improvement.Includes a range of additional unit tests for this issue.
Also includes additional unit tests to safeguard that the behaviour of PHPCS regarding parse errors in chained control structures will not change, as the sniff has a build-in presumption about the PHPCS behaviour with control structures using alternative syntax, so if at any point in the future, the PHPCS token stream for this would change, the sniff will need adjusting.