-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
weak_vendors mode and phars #24853
Comments
I think we should consider that any code being inside a phar is vendor code in this mode. When running a testsuite and having code inside a phar, it is much more likely to be the test runner than the code under test (do you actually build a phar before each test execution, taking into account that this cannot be your executable phar if you are doing unit tests ?) |
@stof I experienced this bug once with a phar, but non-vendor code: it was eval'd code produced by But I agree with you that in doubt, we should consider it vendor code.
good to know :/ |
A simple fix might be to return |
I think I will be able to test this by using |
This PR was merged into the 3.3 branch. Discussion ---------- Have weak_vendors ignore deprecations from outside phar:// and eval() can execute code that may or may not come from the vendors. | Q | A | ------------- | --- | Branch? | 3.3 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | not yet | Fixed tickets | #24853 | License | MIT I haven't managed to get the phar test to pass yet, but before I do, is it ok for me to commit a test phar in Symfony? I'm thinking trust issues? Although the phar is almost plain text. ~~Next, I'm stuck because it looks like symfony does not know how to load classes anymore... should I somehow load `vendor/autoload.php` from the phar or something like that?~~ solved, had nothing to do with that. Commits ------- 9ce0ae2 Have weak_vendors ignore deprecations from outside
When introducing this mode, I overlooked the fact that file paths could look like this:
phar:///usr/local/bin/phpunit-5/phpunit/Util/Fileloader.php
In that kind of case, there is not always a way to tell if the deprecation was triggered inside or outside a vendor, so IMO I should add a special case just for phar paths in that method:
symfony/src/Symfony/Bridge/PhpUnit/DeprecationErrorHandler.php
Lines 64 to 86 in ba3b177
Not sure how
realpath
behave with such paths, BTWI wonder how / if I'm going to be able to test that though... any ideas?
The text was updated successfully, but these errors were encountered: