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)

[balerdis]

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 back parse_partial.
• check_index_coverage correctly flags these files, so the signal is there; what is missing is the recovery.