One unambiguously good thing PHP project could would be to port the parser to Rust, which would unlock the potential for lightning-fast static analysis. Right now anyone venturing into a PHP-specific compiled language tooling has to also write and maintain their own parser, which is out of reach of basically everyone except JetBrains.

I mean, I don't really understand our YACC parser, but I think the main aversion is that we would require a new toolchain which is less "common" and doesn't support all architectures (because people smh use PHP on embedded devices)

But I think that would be neat, I know @pollita was at one point playing around with Rust to make a PHP parser.

@Girgias @mattbrowndev

I did take a whack at this recently, but grmtools was immature and I couldn't find anything better.

I invite anyone who'd like to prove (a) that it's significantly faster to justify having an additional compile complexity, and (b) that it's doable at all.

@pollita @Girgias yeah I don’t think there’s a speed boost to be had — it’s more about the potential speed improvements for tooling (e.g. my all-Rust tool can analyse Hack code 7x faster than similar tooling written in PHP). That speedup would only be important for codebases > 100KLOC though, and given the tools don’t exist it’s a purely theoretical improvement.

@mattbrowndev @pollita Mago which is a new SA tool written by @azjezz in Rust is incredibly speedy.

I think they plan to release the analyser as an individual crate.

@Girgias @pollita @[email protected] though that gets into the other issue, that PHP static analysis is tricky due to magic methods, which traditionally (aka since we started creating SA tools) has been handled with custom PHP extensions performing dynamic reflection. A pure static analysis tool would not be a fit for how PHP is used at most places.

@mattbrowndev @pollita magic methods are truly the bane of existence

@Girgias @pollita could the runtime be made measurably faster in configurable switch turning off magic methods in php.ini?

@mattbrowndev @pollita the only problematic ones would be the get/set/isset/unset methods and possibly the trampoline ones with call/callStatic, or am I missing others?

However I don't think there would be a lot of performance improvements as our inference is quite bad regardless due to "only see one file at a time". I know the JIT helps with that as it has a better picture from what @nielsdos told me.