On Thu, 30 Jul 2020 at 14:28, Joe Ferguson <j...@joeferguson.me> wrote:
> ... I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. > I don't think that's a reasonable summary of this thread at all. I've seen three main types of response: 1) "I haven't followed the discussion about PHPCS, please could you summarise the problem." 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x syntax." 3) "I think #[] will cause as many problems for such tools as @@, just in different places." Maybe they weren't always as polite or succinct as that, but not agreeing with you is not the same as not caring. As far as I can make out, attributes that appear entirely on a single line with no other text are trivial to ignore in any parser whatever the syntax. That trivial case is slightly more trivial with #[] because a PHP 7 parser will treat it as a line comment; but add a rule to your parser to also treat "@@" as a line comment, and you're done. The problems come when you have a) an attribute definition spanning multiple lines, and/or b) an attribute definition inline with other code. As soon as you have that, you have no choice but to parse the code entirely according to the grammar of PHP 8, not as "PHP 7 with some warts". If detecting the end of annotation tokens is really that difficult, would it suffice to make the () mandatory (i.e. @@Deprecated() rather than @@Deprecated)? The rules for what could appear between @@ and ( are pretty simple, and finding the correct ending ) should be pretty much the same effort as finding the correct ending ], since both can occur in matching pairs inside the argument list. Regards, -- Rowan Tommins [IMSoP]
