Update php-parser, fix unary snapshot tests, and make multiple fixes for attribute formatting.#2502
Open
acharron-hl wants to merge 1 commit into
Open
Conversation
…for attribute formatting.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #2293
Fixes #2486
Dependency update note
This PR relies on a new / unpublished version of php-parser (which will likely be version 3.6.1 or 3.7.0.
It should not be merged until that version is published. In the meantime, this PR depends on the commit at the tip of the main branch over there (which includes the unary operator fix.
I was initially setting out to just fix the attribute formatting issues, but that required a new version of the php-parser. Unfortunately the currently published 3.6 has a regression around the unary operator reported as #2486 which means we can't just update to that.
Attribute formatting fixes
Fixes #2293
The updated
php-parserexposes attribute groups as distinct AST nodes on methods, functions, class constants, and enum cases. Prettier-plugin-php needed matching changes so attributes and their comments format correctly.Changes
getCommentChildNodes— attribute groups are now comment attachment targets onfunction/method,classconstant, andenumcase, so comments between#[...]blocks attach to the right node instead of being skipped or misplaced.printAttrs/printAttrGroup— each attribute group is printed throughprintAllComments(), so leading and trailing comments on groups are actually emitted.enumcaseprinting — attributes on enum cases are now printed beforecase(new coverage intests/enum/enum-case-attributes.php).handleClassMemberStatementComments— comments before a property or constant identifier are attached to the enclosing member statement, keeping modifiers likepublic statictogether when comments appear between modifiers and the name.Snapshot impact
tests/attributes/attributes.php#[S]and#[T]now print in place;//Testing Tno longer incorrectly trails the previous method's}.tests/comments/method.php()stays inside parens; inline comments betweenstaticand$fooare all preserved.tests/enum/enum-case-attributes.phpUnary operator / exponentiation fix (upstream parser)
Fixes #2486
This change comes from
php-parser, not from new formatting logic in the plugin. PHP gives**higher precedence than unary+and-, so unparenthesized expressions parse differently from explicitly parenthesized ones:The old parser incorrectly parsed
+$var ** 2as(+$var) ** 2. The formatter faithfully reproduced that wrong AST, so both forms printed identically. The updated parser builds the correct tree — unary wrapping exponentiation for the unparenthesized form, and abin(**)withparenthesizedExpression: truewhen parens are explicit.The plugin's existing
needs-parens.mjsrules already handle both cases correctly; only the snapshots needed updating.Snapshot impact
tests/parens/bin.php$var = +$var ** 2;(+$var) ** 2+($var ** 2)tests/parens/unary.php$a = +$a ** 1;(+$a) ** 1+($a ** 1)Explicitly parenthesized inputs such as
(+$var) ** 2and(+$a) ** 1are unchanged.This is a semantic correction: the old output did not match how PHP actually parses unparenthesized
+$x ** nexpressions.