[ondrejmirtes]

And now a dessert 😉

phpdoc-parser already parses Doctrine annotations (since 1.22.0) to DoctrineTagValueNode. Before, DoctrineAnnotationDecorator printed these nodes back to a string and parsed the string again with StaticDoctrineAnnotationParser, ArrayParser and PlainValueParser. Now the decorator converts the phpdoc-parser nodes directly to DoctrineAnnotationTagValueNode, CurlyListNode, ArrayItemNode and StringNode. The public API does not change.

Removed: StaticDoctrineAnnotationParser, ArrayParser, PlainValueParser, NextTokenType, and the @\FQN text and description splitting in DoctrineAnnotationDecorator.

Changes in behaviour. Rector now uses the phpdoc-parser and Doctrine semantics:

• A multi-line string keeps the * line prefixes in the docblock node, as in doctrine/annotations. When Rector converts it to an attribute, it removes the prefixes.
• A {} list in a {} list is a CurlyListNode. Before, it was a PHP array.
• An integer key stays an integer: {1="Foo"}. ArrayItemNode now prints integer keys. Before, a changed annotation lost them.
• A nested annotation that is a positional argument has the key null. Before, the key was 0.
• Single-quoted strings and quoted argument keys are not Doctrine syntax: @Foo('bar'), @Foo("key"="value"). phpdoc-parser gives InvalidTagValueNode for them, and Rector does not change them. Fixtures are updated.

Needs rectorphp/rector-doctrine#543 to be merged first.

[ondrejmirtes]

This is ready.

[TomasVotruba]

Thanks the updates 👍 Great to have these glitches resolve out of the box. I think we can leave the invalid docblock in Doctrine tags behind.

Let's merge 🚀

[bbrala]

MIght regres drupal rector a bit this, not 100% sure yet. We used part of this code to do annotation to attribute conversion for Drupal

[TomasVotruba]

We still do annotation to attributes conversion as before.
Can you share broken example? https://getrector.com/demo uses latest dev-main Rector

[bbrala]

Yeah will investigate and post back if there work in rector.

[bbrala]

Well, seems this is not really an issue, but i did find a discrepancy between doctrines parser and rector.

https://getrector.com/demo/0ffc42df-7754-41b2-969e-b8e30dde6c1e

- doctrine/annotations (upstream, 2.0.x): the lexer skips whitespace and * between tokens; 
   in DocLexer::getNonCatchablePatterns() they are ['\s+', '\*+', '(.)']. The parser's MethodCall() 
   then checks whether the next token is (, so a newline plus * before the ( doesn't matter.
- Drupal's copy (Drupal\Component\Annotation\Doctrine\DocParser) uses the same lexer 
   patterns. I ran it on both forms from the demo and got the same values for each:
      next line: [{"id":"next_line","label":"Next line"}]
      same line: [{"id":"same_line","label":"Same line"}]

The cause is that PHPStan's phpdoc-parser, which Rector uses, only treats the tag as a Doctrine annotation when the ( comes straight after the tag name. Otherwise it gives the tag a plain text value. Rector's rule then turns that plain tag into an attribute with no arguments and drops the docblock text, so data is lost.

But it seems this might not be a rector issue but a phpstan issue ;x

[samsonasik]

@bbrala how often the open parentheses on new line happen in projects?

[bbrala]

I only found one oublic drupal modules with this pattern. So I guess not that much. I dont know custom code of course. But its not wide spread

[samsonasik]

@ondrejmirtes can parentheses in new line be supported, that would be great if it works out of the box

[bbrala]

It would need to be more greedy and do newlines. Might have performance implicatio s. Im not sure of the real life impact, but it would be more correct since that is how the doctrine parser works.

[samsonasik]

as this changing code, correctness should more important than speed so it would be great if this not cause regression on allowed annotation syntax so would be great to have support out of the box.