New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception: class_alias with non-literal parameters is not allowed when WholeProgram optimizations are turned on #867

Closed
raulp opened this Issue Jul 19, 2013 · 33 comments

Comments

Projects
None yet
10 participants
@raulp

raulp commented Jul 19, 2013

after installing from deb packages on ubuntu, i was trying to compile a list of php files in my folder.
I've got:

Exception: class_alias with non-literal parameters is not allowed when WholeProgram optimizations are turned on\n
hphp failed

Any clue what i might do ?

@paroski

This comment has been minimized.

Show comment
Hide comment
@paroski

paroski Jul 19, 2013

WholeProgram optimizations rely on being able to determine certain things about types when doing global analysis. Using class_alias() with non-literal parameters makes it very difficult to prove certain things about types during analysis. There are some trivial cases where in theory WholeProgram optimization could make it work, for example:

function my_class_alias($x,$y) { class_alias($x,$y); }
my_class_alias('Foo', 'Bar');

In the example above, WholeProgram optimization could in theory see what literal strings are ultimately getting passed into class_alias(). However, in the general case it is not always possible to reliably determine what literal strings get passed to class_alias(), since the strings could come from some external source like a database, or the strings could be computed using some Turing-complete logic, etc.

The short answer: you should either turn off WholeProgram optimization for you program, or find a way to change your program to avoid using non-literal parameters with class_alias().

paroski commented Jul 19, 2013

WholeProgram optimizations rely on being able to determine certain things about types when doing global analysis. Using class_alias() with non-literal parameters makes it very difficult to prove certain things about types during analysis. There are some trivial cases where in theory WholeProgram optimization could make it work, for example:

function my_class_alias($x,$y) { class_alias($x,$y); }
my_class_alias('Foo', 'Bar');

In the example above, WholeProgram optimization could in theory see what literal strings are ultimately getting passed into class_alias(). However, in the general case it is not always possible to reliably determine what literal strings get passed to class_alias(), since the strings could come from some external source like a database, or the strings could be computed using some Turing-complete logic, etc.

The short answer: you should either turn off WholeProgram optimization for you program, or find a way to change your program to avoid using non-literal parameters with class_alias().

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 19, 2013

Hey Paroski
Not sure if you're familiar, but i'm trying to move laravel ( which is a php framework ) to HipHop.
So far, all i did was installing HipHop ( apt-get install ).
Then, i wanted to add all the php files with something like:
hhvm --hphp -k 1 -o /tmp/app/ --input-list /tmp/files.list -l 1

Then, i got that error ( which now i understand what it means - not sure if i can change that though ) and lots of file not found ( Unable to stat file ... ), which is weird, as those files paths are not in /tmp/files.list. Do you know why i get those too ?

Thanks !

raulp commented Jul 19, 2013

Hey Paroski
Not sure if you're familiar, but i'm trying to move laravel ( which is a php framework ) to HipHop.
So far, all i did was installing HipHop ( apt-get install ).
Then, i wanted to add all the php files with something like:
hhvm --hphp -k 1 -o /tmp/app/ --input-list /tmp/files.list -l 1

Then, i got that error ( which now i understand what it means - not sure if i can change that though ) and lots of file not found ( Unable to stat file ... ), which is weird, as those files paths are not in /tmp/files.list. Do you know why i get those too ?

Thanks !

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 19, 2013

Contributor

I believe those "unable to stat file" statements can be ignored.

Since you don't control this code, the best suggestion is not to use WholeProgram mode.
(Add -v WholeProgram=false to the commandline.)

Contributor

scannell commented Jul 19, 2013

I believe those "unable to stat file" statements can be ignored.

Since you don't control this code, the best suggestion is not to use WholeProgram mode.
(Add -v WholeProgram=false to the commandline.)

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 19, 2013

Even stranger now :)
/home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertion m_sym' failed. /home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertionm_sym' failed.
hphp failed

Thanks guys for helping me with this.

Btw, just to be sure, the steps are like i said ?

  1. install
  2. hhvm --hphp ...
  3. hhvm -m daemon --config .... ?

raulp commented Jul 19, 2013

Even stranger now :)
/home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertion m_sym' failed. /home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertionm_sym' failed.
hphp failed

Thanks guys for helping me with this.

Btw, just to be sure, the steps are like i said ?

  1. install
  2. hhvm --hphp ...
  3. hhvm -m daemon --config .... ?
@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 19, 2013

Contributor

@raulp, can you give us a small piece of code that reproduces the assertion so we can investigate that further?

Contributor

scannell commented Jul 19, 2013

@raulp, can you give us a small piece of code that reproduces the assertion so we can investigate that further?

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 19, 2013

scannell, what exactly should i give you ?
It does not say on what file :)

Here's what you can do: try to add https://github.com/laravel/laravel this to HipHop. I guess that kind of what i have. A Laravel installation with some custom things.
Or you can install it on your server, it's very easy, 2 command lines

raulp commented Jul 19, 2013

scannell, what exactly should i give you ?
It does not say on what file :)

Here's what you can do: try to add https://github.com/laravel/laravel this to HipHop. I guess that kind of what i have. A Laravel installation with some custom things.
Or you can install it on your server, it's very easy, 2 command lines

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 19, 2013

Contributor

@raulp, I have a repro on the AliasLoader from laravel. I'll follow up.

Contributor

scannell commented Jul 19, 2013

@raulp, I have a repro on the AliasLoader from laravel. I'll follow up.

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 19, 2013

Thanks man ! Really appreciate it !

raulp commented Jul 19, 2013

Thanks man ! Really appreciate it !

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 22, 2013

@scannell , whenever you have some updates, please do let me know :) the Laravel community will appreciate it. And if we can find a way to make it work, i know lots of ppl that will use it in their systems.

Thanks again !

raulp commented Jul 22, 2013

@scannell , whenever you have some updates, please do let me know :) the Laravel community will appreciate it. And if we can find a way to make it work, i know lots of ppl that will use it in their systems.

Thanks again !

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 22, 2013

Contributor

@raulp, internally we don't use WholeProgram = false very often so we don't test that much with it. I know you don't really care to use it besides that class_alias doesn't work in WholeProgram mode because it invalidates some optimization assumptions we are making.

As a workaround in the meantime, if you temporarily remove AliasLoader::load function (are you using this part of laravel in your application?) from the laravel source, does what you are trying to do work for you?

Contributor

scannell commented Jul 22, 2013

@raulp, internally we don't use WholeProgram = false very often so we don't test that much with it. I know you don't really care to use it besides that class_alias doesn't work in WholeProgram mode because it invalidates some optimization assumptions we are making.

As a workaround in the meantime, if you temporarily remove AliasLoader::load function (are you using this part of laravel in your application?) from the laravel source, does what you are trying to do work for you?

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 22, 2013

Contributor

Also, @raulp, curious: what is your use case for repo construction? (Our gut is that not many people outside Facebook are using this so we're wondering.)

Contributor

scannell commented Jul 22, 2013

Also, @raulp, curious: what is your use case for repo construction? (Our gut is that not many people outside Facebook are using this so we're wondering.)

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 22, 2013

@scannell i think Laravel uses the AliasLoader in the core. So finding where that is used can be a problem.
But, when i tried to use WholeProgram ( set it to false ), i still got errors. Are they related ?
The error was

/home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertionm_sym' failed.
hphp failed

raulp commented Jul 22, 2013

@scannell i think Laravel uses the AliasLoader in the core. So finding where that is used can be a problem.
But, when i tried to use WholeProgram ( set it to false ), i still got errors. Are they related ?
The error was

/home/sgolemon/dev/hiphop-php/hphp/compiler/expression/simple_variable.cpp:87: bool HPHP::SimpleVariable::couldBeAliased() const: assertionm_sym' failed.
hphp failed

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 22, 2013

@scannell can you detail that please ( repo construction ) ... not sure what you mean by that.

raulp commented Jul 22, 2013

@scannell can you detail that please ( repo construction ) ... not sure what you mean by that.

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 22, 2013

Contributor

What I mean is that we normally run with WholeProgram = true when we construct a bytecode repository. We don't use class_alias internally so it does not cause issues. We don't run often with WholeProgram = false so it is very possible there are bugs (like that assertion.)

class_alias not working with WholeProgram = true is expected for the reasons we stated; the assertion is not.

My question on repo construction is this: one does not have to precompile the PHP code into a bytecode repository using hhvm --hphp in order to run PHP code on HHVM, so I was just wondering why you were doing so instead of just running with the repo being populated at runtime as your PHP code is parsed and executed. If you need to use something with class_alias, I believe you'll be able to do so as long as you don't run in repository mode with a pre-compiled repository. Does that make sense?

Contributor

scannell commented Jul 22, 2013

What I mean is that we normally run with WholeProgram = true when we construct a bytecode repository. We don't use class_alias internally so it does not cause issues. We don't run often with WholeProgram = false so it is very possible there are bugs (like that assertion.)

class_alias not working with WholeProgram = true is expected for the reasons we stated; the assertion is not.

My question on repo construction is this: one does not have to precompile the PHP code into a bytecode repository using hhvm --hphp in order to run PHP code on HHVM, so I was just wondering why you were doing so instead of just running with the repo being populated at runtime as your PHP code is parsed and executed. If you need to use something with class_alias, I believe you'll be able to do so as long as you don't run in repository mode with a pre-compiled repository. Does that make sense?

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 22, 2013

@scannell , thanks for all the info.
I've got the idea with the class_alias and WholeProgram. I'll try to get with the creator and see if we can change that later on.

Hmm, about the second part, that's who i've read everywhere that i have to get up and running. Maybe i did it all wrong ?
Can you tell me the exact steps to get a Laravel default app running on HipHop ? And my question will be ... if i'm not pre-compiling the code, is it worth it to run it with HipHop ?

raulp commented Jul 22, 2013

@scannell , thanks for all the info.
I've got the idea with the class_alias and WholeProgram. I'll try to get with the creator and see if we can change that later on.

Hmm, about the second part, that's who i've read everywhere that i have to get up and running. Maybe i did it all wrong ?
Can you tell me the exact steps to get a Laravel default app running on HipHop ? And my question will be ... if i'm not pre-compiling the code, is it worth it to run it with HipHop ?

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Jul 22, 2013

Contributor

It is most likely still worth it. One just incurs the overhead of parsing and repo construction the first time a unit of PHP code is executed. Subsequent runs will execute from the repo. One can save a bit of time parsing ahead of time but assuming your application is a long-running server application it will be a bit slower to warm up but then will execute from the dynamically built repository.

Per the high-level instructions at https://github.com/facebook/hiphop-php, you should just be able to run a script with hhvm <scriptname> and server mode with something like sudo hhvm -m server and then making the appropriate web requests. The precompilation step is optional. (I am guessing a lot of what you read pertains to the former HPHPC days when were compiling PHP to C++; this is no longer required.)

Hope this helps!

Contributor

scannell commented Jul 22, 2013

It is most likely still worth it. One just incurs the overhead of parsing and repo construction the first time a unit of PHP code is executed. Subsequent runs will execute from the repo. One can save a bit of time parsing ahead of time but assuming your application is a long-running server application it will be a bit slower to warm up but then will execute from the dynamically built repository.

Per the high-level instructions at https://github.com/facebook/hiphop-php, you should just be able to run a script with hhvm <scriptname> and server mode with something like sudo hhvm -m server and then making the appropriate web requests. The precompilation step is optional. (I am guessing a lot of what you read pertains to the former HPHPC days when were compiling PHP to C++; this is no longer required.)

Hope this helps!

@raulp

This comment has been minimized.

Show comment
Hide comment
@raulp

raulp Jul 22, 2013

@scannell yeah, most of the docs are based on HPHPc. Ok, i'll try to give it a shot without compiling ( i think i've tried, but i had an error with empty repository, and every request failed )
I did create a hhvm config file like here: http://www.hiphop-php.com/wp/?p=113 , but maybe i missed something
I'm gonna try again !

raulp commented Jul 22, 2013

@scannell yeah, most of the docs are based on HPHPc. Ok, i'll try to give it a shot without compiling ( i think i've tried, but i had an error with empty repository, and every request failed )
I did create a hhvm config file like here: http://www.hiphop-php.com/wp/?p=113 , but maybe i missed something
I'm gonna try again !

@ptarjan

This comment has been minimized.

Show comment
Hide comment
@ptarjan

ptarjan Dec 7, 2013

Contributor

laravel works on trunk

Contributor

ptarjan commented Dec 7, 2013

laravel works on trunk

@ptarjan ptarjan closed this Dec 7, 2013

@scannell

This comment has been minimized.

Show comment
Hide comment
@scannell

scannell Dec 7, 2013

Contributor

I suspect it still doesn't work with WholeProgram mode enabled -- because @jdelong wasn't entirely sure what we could do here even -- but I'd suggest just not using RepoAuthoritative mode if one has to include this code (or removing it from one's local laravel installation if need be -- even if we allowed it during compilation, calling class_alias would break things badly, or we'd have to make significant changes to how WholeProgram mode works.) What is unfortunate is we haven't really spent much time running hhvm --hphp not in WholeProgram mode but it's unlikely to be something we're going to spend time on any time in the next year.

Contributor

scannell commented Dec 7, 2013

I suspect it still doesn't work with WholeProgram mode enabled -- because @jdelong wasn't entirely sure what we could do here even -- but I'd suggest just not using RepoAuthoritative mode if one has to include this code (or removing it from one's local laravel installation if need be -- even if we allowed it during compilation, calling class_alias would break things badly, or we'd have to make significant changes to how WholeProgram mode works.) What is unfortunate is we haven't really spent much time running hhvm --hphp not in WholeProgram mode but it's unlikely to be something we're going to spend time on any time in the next year.

@jdelong

This comment has been minimized.

Show comment
Hide comment
@jdelong

jdelong Dec 7, 2013

Contributor

Yeah it doesn't work in RepoAuthoritative mode (and likely won't), because it breaks assumptions needed for static analysis.

With RepoAuthoritative=false it should work though.

Contributor

jdelong commented Dec 7, 2013

Yeah it doesn't work in RepoAuthoritative mode (and likely won't), because it breaks assumptions needed for static analysis.

With RepoAuthoritative=false it should work though.

@PLaRoche

This comment has been minimized.

Show comment
Hide comment
@PLaRoche

PLaRoche Dec 17, 2014

Hi guys, hate to resurrect an old thread, but we are exploring compiling our entire laravel framework to byte code (instead of JIT compilation), did anything come of this / get resolved?

PLaRoche commented Dec 17, 2014

Hi guys, hate to resurrect an old thread, but we are exploring compiling our entire laravel framework to byte code (instead of JIT compilation), did anything come of this / get resolved?

@paulbiss

This comment has been minimized.

Show comment
Hide comment
@paulbiss

paulbiss Dec 17, 2014

Contributor

Even when executing in non-RepoAuthoritative mode PHP is compiled to bytecode, and when running in RepoAuthoritative mode the JIT is still used to generate machine instructions at runtime. The main difference between these two modes is a set of optimizations that are run statically to transform the bytecode based on whole-program analysis.

Contributor

paulbiss commented Dec 17, 2014

Even when executing in non-RepoAuthoritative mode PHP is compiled to bytecode, and when running in RepoAuthoritative mode the JIT is still used to generate machine instructions at runtime. The main difference between these two modes is a set of optimizations that are run statically to transform the bytecode based on whole-program analysis.

@PLaRoche

This comment has been minimized.

Show comment
Hide comment
@PLaRoche

PLaRoche Dec 18, 2014

One of our goals is to actually have the byte code (vs the php code) to "pass around". Hence, needing a way to precompile the php into byte code. We have been successful in doing this with parts of what we have, but not the entire framework, was hoping that perhaps the above issues had been resolved by now.

PLaRoche commented Dec 18, 2014

One of our goals is to actually have the byte code (vs the php code) to "pass around". Hence, needing a way to precompile the php into byte code. We have been successful in doing this with parts of what we have, but not the entire framework, was hoping that perhaps the above issues had been resolved by now.

@fredemmott

This comment has been minimized.

Show comment
Hide comment
@fredemmott

fredemmott Dec 18, 2014

Contributor

Sorry, but repo mode is always going to have limitations on which dynamic constructs are allowed (very few). It seems unlikely that we will change this one.

Contributor

fredemmott commented Dec 18, 2014

Sorry, but repo mode is always going to have limitations on which dynamic constructs are allowed (very few). It seems unlikely that we will change this one.

@tylermenezes

This comment has been minimized.

Show comment
Hide comment
@tylermenezes

tylermenezes Apr 2, 2015

If it's useful to anyone, disabling optimizations (--optimize-level=0) and disabling whole-program mode as specified above will make this sort of work (read: break differently). The repo is created successfully, but it throws a new error when you try to use it: HipHop Parse Error: Native functions/methods may only be defined in systemlib

tylermenezes commented Apr 2, 2015

If it's useful to anyone, disabling optimizations (--optimize-level=0) and disabling whole-program mode as specified above will make this sort of work (read: break differently). The repo is created successfully, but it throws a new error when you try to use it: HipHop Parse Error: Native functions/methods may only be defined in systemlib

@onlyone0001

This comment has been minimized.

Show comment
Hide comment
@onlyone0001

onlyone0001 May 23, 2015

@tylermenezes Have you found a way further? I got stuck in the same place.

onlyone0001 commented May 23, 2015

@tylermenezes Have you found a way further? I got stuck in the same place.

@PLaRoche

This comment has been minimized.

Show comment
Hide comment
@PLaRoche

PLaRoche May 24, 2015

We've had no luck but are still looking for a solution

PLaRoche commented May 24, 2015

We've had no luck but are still looking for a solution

@onlyone0001

This comment has been minimized.

Show comment
Hide comment
@onlyone0001

onlyone0001 May 24, 2015

Is there an option to exclude some files from compiling but including them without compilation?

onlyone0001 commented May 24, 2015

Is there an option to exclude some files from compiling but including them without compilation?

@paulbiss

This comment has been minimized.

Show comment
Hide comment
@paulbiss

paulbiss May 25, 2015

Contributor

No. For whole program analysis to work the compiler needs to have access to any code that will ever execute. The byteocde repo itself is still constructed in non-repo mode and can be used without enabling repo-authoritative mode if all you're looking for is precomputed bytecode.

I should stress that compiling a repo has basically no value as a form of obfuscation, and transformation back into PHP is a trivial process.

Contributor

paulbiss commented May 25, 2015

No. For whole program analysis to work the compiler needs to have access to any code that will ever execute. The byteocde repo itself is still constructed in non-repo mode and can be used without enabling repo-authoritative mode if all you're looking for is precomputed bytecode.

I should stress that compiling a repo has basically no value as a form of obfuscation, and transformation back into PHP is a trivial process.

@onlyone0001

This comment has been minimized.

Show comment
Hide comment
@onlyone0001

onlyone0001 May 25, 2015

Trivial sounds underestimating?
We are already disabling whole program analysis (-v WholeProgram=false) and disabling optimize level (--optimize-level=0) for successful compiling. Logically it should be possible to exclude some files from compiling and including them as is for runtime processing.

onlyone0001 commented May 25, 2015

Trivial sounds underestimating?
We are already disabling whole program analysis (-v WholeProgram=false) and disabling optimize level (--optimize-level=0) for successful compiling. Logically it should be possible to exclude some files from compiling and including them as is for runtime processing.

@PLaRoche

This comment has been minimized.

Show comment
Hide comment
@PLaRoche

PLaRoche May 25, 2015

I'm also curious about "trivial". Do you mean trivial in the way all byte code is somewhat easy to be "un compiled" into some sort of legible original form, or do you mean, by nature of using hhvm to compile the php code, their is an amazingly easy way to transform back to php?

PLaRoche commented May 25, 2015

I'm also curious about "trivial". Do you mean trivial in the way all byte code is somewhat easy to be "un compiled" into some sort of legible original form, or do you mean, by nature of using hhvm to compile the php code, their is an amazingly easy way to transform back to php?

@paulbiss

This comment has been minimized.

Show comment
Hide comment
@paulbiss

paulbiss May 25, 2015

Contributor

Trivial is absolutely not underestimating. Transforming bytecode back to PHP is itself a rather straightforward process (for a short enough piece anyone familiar enough with the way our emitter works could do it off the top of their head). In addition there's a great deal of metadata that needs to be stored alongside the bytecode (for error messages, backtraces, and other PHPisms).

The point here is that in addition to recovering logic and control flow you could recover variable, function, constant, trait, interface, and class names, modifiers on classes, functions, and properties, line numbers, and doc-comments. Depending on how sophisticated you want to be you can pretty much generate something every bit as legible as the original source.

While I'm not saying that writing a decompiler would itself be a "simple" task (I suppose it would be at least as complicated as the emitter that generated the bytecode), it's not exactly a particularly technically challenging problem in the grand scheme of things. With the bytecode and the metadata we're not just talking about reconstructing some of the logic, you could more or less recover the source in some nearly equivalent form.

Contributor

paulbiss commented May 25, 2015

Trivial is absolutely not underestimating. Transforming bytecode back to PHP is itself a rather straightforward process (for a short enough piece anyone familiar enough with the way our emitter works could do it off the top of their head). In addition there's a great deal of metadata that needs to be stored alongside the bytecode (for error messages, backtraces, and other PHPisms).

The point here is that in addition to recovering logic and control flow you could recover variable, function, constant, trait, interface, and class names, modifiers on classes, functions, and properties, line numbers, and doc-comments. Depending on how sophisticated you want to be you can pretty much generate something every bit as legible as the original source.

While I'm not saying that writing a decompiler would itself be a "simple" task (I suppose it would be at least as complicated as the emitter that generated the bytecode), it's not exactly a particularly technically challenging problem in the grand scheme of things. With the bytecode and the metadata we're not just talking about reconstructing some of the logic, you could more or less recover the source in some nearly equivalent form.

@paulbiss

This comment has been minimized.

Show comment
Hide comment
@paulbiss

paulbiss May 25, 2015

Contributor

With respect to partial compilation without optimizations, that's already done for you when you execute the code. To run PHP even in non-repo mode we require bytecode so it's generated on the fly and cached in an sqlite db (if you set Repo.Central.Path in your settings that's where it will be stored). As files are parsed for the first time their bytecode and metadata will be added to the repository.

AIUI we don't have a mode to generate such a repo ahead of time that's not intended to be complete, I'm not totally convinced of any use cases for this (see my answer above about the futility of obfuscation by bytecode repo), generally speaking the only advantage to pre-compiling the repo is to do more sophisticated ahead of time static analysis (for which the repo must be complete).

Contributor

paulbiss commented May 25, 2015

With respect to partial compilation without optimizations, that's already done for you when you execute the code. To run PHP even in non-repo mode we require bytecode so it's generated on the fly and cached in an sqlite db (if you set Repo.Central.Path in your settings that's where it will be stored). As files are parsed for the first time their bytecode and metadata will be added to the repository.

AIUI we don't have a mode to generate such a repo ahead of time that's not intended to be complete, I'm not totally convinced of any use cases for this (see my answer above about the futility of obfuscation by bytecode repo), generally speaking the only advantage to pre-compiling the repo is to do more sophisticated ahead of time static analysis (for which the repo must be complete).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment