Repository navigation
PHP: symbols declared after an inline-HTML block never reach the graph, and the whole tail of a valid file is reported parse_partial (0.10.8) #2000
Description
Summary
In a syntactically valid PHP file, everything after an inline-HTML block (?> ... <?php) is reported as parse_partial, and symbols declared in that tail are missing from the graph — not "may be missing". The file is never listed as skipped, so the coverage report says it was indexed.
This is the dominant shape of PHP in legacy applications: a view file that closes the tag, emits markup, and reopens. In one real repository it accounts for 909 own-code files flagged whole-file, which makes graph evidence unusable for that layer.
Minimal reproduction
Two files, both accepted by php -l:
plain.php
<?php
function alpha() { return 1; }
function beta() { return alpha(); }inline_html.php
<?php
function gamma() { return 2; }
?>
<div class="box">
<p>plain markup after the closing tag</p>
</div>
<?php
function delta() { return gamma(); }$ php -l plain.php
No syntax errors detected in plain.php
$ php -l inline_html.php
No syntax errors detected in inline_html.php
Then index_repository(repo_path=..., mode="full").
Observed
"skipped_count": 0,
"parse_partial_count": 1,
"parse_partial": {"files": [{"path": "inline_html.php", "error_ranges": "3-8,8-8"}]}3-8 on an 8-line file: everything from the closing tag onward. And the symbol declared in that tail is simply absent:
$ search_graph(label="Function")
total: 3
gamma Function 2-2 (inline_html.php)
alpha Function 2-2 (plain.php)
beta Function 3-3 (plain.php)
delta is not there, and neither is its call to gamma.
Expected
Inline HTML is not a parse failure — it is ordinary PHP. Parsing should resume at the next <?php and pick up what follows, so delta lands in the graph and only the markup region (if anything) is reported.
Failing that, the honest fallback would be for the report to distinguish "this region is markup we skipped by design" from "this region did not parse", because today the two are indistinguishable and a whole-file parse_partial reads as a broken file rather than a normal one.
Notes
- Version: 0.10.8, Linux x86-64, stdio server.
- The same shape appears in SQL template files that carry
{...}placeholders: the whole file comes backparse_partial. check_index_coveragecorrectly flags these files, so the signal is there; what is missing is the recovery.
Activity
DeusData commentedon Sep 3, 2026
Thank you for the small valid-PHP fixture and for checking graph contents rather than relying only on the coverage count.
Current
mainroutes PHP through thetree_sitter_php_onlygrammar configuration, and there is no mixed-content reparse path that would recover declarations after an inline-HTML region. That matches the missingdeltanode in your reproduction and makes this a concrete extraction gap, not merely noisy coverage reporting.I have routed this as a high-priority parsing bug. No more information is needed at this stage; thank you for quantifying the real-repository impact as well as supplying the eight-line case.
docs: cerrar la deuda de reportar los dos defectos de CBM
harshitaajoshi commentedon Sep 27, 2026
Hi, I've opened #2389 for this.
The fix replaces the inline HTML with spaces before parsing, so the existing
php_onlygrammar can read past?>. The file keeps its length and line breaks, so line numbers don't change.?>becomes a statement terminator,<?=keeps the echoed calls, and?>inside strings, heredocs and comments is left alone.It includes your
inline_html.phpcase as a regression test, plus template edge cases and a pipeline test for thedelta -> gammaedge. On theAutomattic/_stheme, PHP files flaggedparse_partialwent from 17 to 0.fix(extract): address review on PHP inline-HTML masking (DeusData#2000)
test(extract): pin PHP mask copy-on-write via arena allocation total (D…
fix(extract): parse PHP past inline HTML so symbols after ?> reach th…
fix(extract): address review on PHP inline-HTML masking (DeusData#2000)
test(extract): pin PHP mask copy-on-write via arena allocation total (D…
fix(extract): parse PHP past inline HTML so symbols after ?> reach th…
fix(extract): address review on PHP inline-HTML masking (DeusData#2000)
test(extract): pin PHP mask copy-on-write via arena allocation total (D…
Merge pull request #2389 from harshitaajoshi/fix/php-inline-html-2000
DeusData commentedon Nov 3, 2026
Fixed on main in 190abae (#2389, thanks to @harshitaajoshi): the PHP extractor now parses past inline-HTML blocks, so symbols declared after ?> reach the graph and the rest of a valid file is no longer reported parse_partial.