Proposal: Support overriding short_open_tag in token_get_all() #9612
+65
−9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Details ------- Add the flags TOKEN_ENABLE_SHORT_OPEN_TAG/TOKEN_DISABLE_SHORT_OPEN_TAG to `token_get_all` and `PhpToken::tokenize()` If both flags are accidentally combined, TOKEN_DISABLE_SHORT_OPEN_TAG takes precedence. If neither bit flag is provided, then token_get_all continues to use the value of the system ini setting `short_open_tag` - https://www.php.net/manual/en/ini.core.php#ini.short-open-tag Motivation ---------- - Allow linters/analyzers/IDEs to parse/analyze/lint projects targeting a deployment environment supporting short open tags/no short open tags, regardless of what the user configured locally. - Make it more convenient to programmatically convert short open tags to standard `<?php` tags in migration scripts - Allow linters/scripts to easily warn about code with short open tags that would be echoed instead of compiled/run (T_INLINE_HTML) when short tags are disabled - In applications/libraries that use token_get_all, avoid platform dependence when running the test suites (in PHP versions including this change). (And make it convenient to test both setting versions in the same test suite) Implementation details ---------------------- When preparing to scan tokens from a string or from a file, this copies constant `CG(short_tags)` corresponding to the system ini setting `short_open_tags` to `SCNG(short_tags)`. PHP modules such as `tokenizer` can then conditionally override it after the call to `zend_prepare_string_for_scanning` (PECLs can also make use of this safely starting) To handle edge cases such as compilation triggering an error handler which calls token_get_all, zend_save_lexical_state and zend_restore_lexical_state also save/restore `short_tags`
TysonAndre
force-pushed
the
short-tags-tokenize
branch
from
4e9b314 to
580109a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Details
Add the flags TOKEN_ENABLE_SHORT_OPEN_TAG/TOKEN_DISABLE_SHORT_OPEN_TAG to
token_get_allandPhpToken::tokenize()If both flags are accidentally combined,
TOKEN_DISABLE_SHORT_OPEN_TAG takes precedence.
If neither bit flag is provided, then token_get_all continues to use the value of the system ini setting
short_open_tagMotivation
<?phptags in migration scriptsImplementation details
When preparing to scan tokens from a string (or from a file), this copies constant
CG(short_tags)corresponding to the system ini settingshort_open_tagstoSCNG(short_tags)(scanner globals).PHP modules such as
tokenizercan then conditionally override it after the call tozend_prepare_string_for_scanning(PECLs can also make use of this safely starting)To handle edge cases such as compilation triggering an error handler which calls token_get_all, zend_save_lexical_state and zend_restore_lexical_state also save/restore
short_tagsOther Notes
This deliberately does not deprecate short open tags or change default settings and that is not planned. A previous RFC by another developer aimed to deprecate short open tags entirely but that did not go through.