Resolve all files in a project during AOT compilation (Composer integration)

[ircmaxell]

Figure out a way to determine all classes/files in a project, and compile all of them in one shot.

This needs to be able to handle non-class files seamlessly.

[driusan]

I'm not sure that this is possible in all cases. how can you exhaustively know what files autoloaders might touch if someone does:

// please don't do this.
$x = new $_GET['classname'];

[ircmaxell]

Well, that's where something like a manifest or command line files could come in handy.

What I'm thinking, is we add support for composer which should handle the 98% use-case. Then turn any code like the above into a runtime error if it can't find the class. And then provide a way to declare "compile these other non-composer dependencies as well".

The one thing that'd be hard is eval support, but that's possible anyway by linking in the compiler even to AOT compiled code...

[PurHur]

Shouldnt be all files in the scope get loaded in the binary? Like all other requests they wont care about a lot off the classes but they will be still present in the compiled binary of a big application!?

So if all files from an static(!) autoloader are included on compile time this should not be a problem at all.

Edit: I would prefer a blacklist of files which are not included.

[driusan]

I agree that just pessimistically assuming anything might be included and using dead code elimination to get rid of the things that aren't is the way to go, but what are you proposing for determining what "all files in the scope" are?

(I think a first pass could use the CFG graph for any includes starting from the entry point once #62 is fixed, and a second pass can pessimistically eval any autoload functions for classes that are instantiated with new and assume those should be included, and then a third pass could add a whitelist of any extra files. I don't think any special treatment would be needed for composer, since at some point vendor/autoload.php would have had to have been included.)

[PurHur]

I have the current php application crazyness in mind. PHP is easy and can be used 42 different ways. The PHP-compiler shouldnt make it harder. So if this works out of the box for most of the software out there without complicate makefiles/manifests files the acceptance will be better. (Yes thats not the current goal)

The docroot of an application should contains mostly all files. It would be possible to inject even furthermore files but the standard http server wont allow that in the default conf. "Out of docroot"... so the majority of php software out there has all *.php files ready to run/"compile" in one docroot. That is what php-src does.

I dont even want the composer autoloader thing in the compiler-core. If composer is able to generate a static classmap then this could easily integrated into a makefile.

I turn the question around. Which php files should the compiler not load? And why?

[ircmaxell]

@PurHur that's exactly how I'm thinking about it. Scan for all files/folders, and "include" everything. (note, side-effects due to compiling PHP with code in it won't actually happen since those require/include calls are turned into function calls with the global code inside the function).

The only complexity is conditionally defined code, and in those cases we'd need to compile both to something like a function pointer and conditionally switch which function pointer is used (or use dynamic dispatch for those functions, just like string functions).