Skip to content

0.2.4#11

Merged
math3usmartins merged 4 commits into
mainfrom
0.2.x
Jun 14, 2026
Merged

0.2.4#11
math3usmartins merged 4 commits into
mainfrom
0.2.x

Conversation

@math3usmartins

Copy link
Copy Markdown
Member

No description provided.

math3usmartins and others added 4 commits June 14, 2026 00:40
An EOF-anchored syntax error (unterminated comment, "unexpected EOF")
made the server emit a diagnostic whose range end was one character past
end-of-document: nikic reports a 1-based BYTE `endColumn` of
`lineLength + 1` at EOF, which `buildParseErrorDiagnostic` used verbatim.
A strict LSP annotator (PhpStorm) throws `Range must be inside element
being annotated` when asked to render that range mid-edit, poisoning the
diagnostics provider for the rest of the session.

Clamp every emitted range into the analyzed buffer:

  - PositionMap gains `clampPosition` / `clampRange` primitives (UTF-16
    aware, reusing the extracted `lineUtf16Length`).
  - `Analyzer::buildParseErrorDiagnostic` clamps at the source so the
    internal Diagnostic is never out of bounds.
  - `XphpDiagnosticsProvider` clamps at the wire boundary via a cached
    PositionMap (`toLspClamped`) as defense-in-depth across parse,
    undefined-name, and workspace diagnostics. `DiagnosticTranslator`
    stays pure.

Why it escaped: nothing asserted that emitted ranges stay within
document bounds, and the Behat "underlines" step routed through
`positionToOffset`, which silently clamps past-EOL. Adds the
`AssertsRangeWithinDocument` invariant (proven to fail pre-fix on the
EOF cases), PositionMap clamp + characterization tests, a provider-level
wire test, and a Behat bounds step + unterminated-comment scenario.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Release 0.2.4.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Hovering a property accessed through a generic receiver showed the raw
declared type parameter (`public A $first`) instead of the concrete type,
even though the variable-inference path already computed the substituted
type (the assigned `$x = $pair->first` hover showed `Pair<Plastic, User>`).

Wire the existing substitution into the member-hover path:

  - GenericResolver gains `resolvePropertyTypeAt`, which finds the
    PropertyFetch at the cursor and renders its substituted type via the
    existing `resolvePropertyFetch` (same machinery the assignment-tracking
    path uses -- no new substitution logic).
  - PhpHoverResolver passes that type into `renderProperty`, which prefers
    it over `prettify(inferredType)` and falls back cleanly when the
    receiver isn't a tracked generic instantiation.

Now `$nested->swap()->first` hovers as
`public App\...\Pair<App\...\Plastic, App\...\User> $first`, matching the
LHS-variable hover. Covers the direct-receiver and chained-method-call
cases with tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
End-to-end scenarios through the real hover handler: a property accessed
through a direct generic receiver (`$pair->first` on `Pair<Plastic, User>`)
and through a chained generic method call (`$nested->swap()->first`) both
hover with the substituted concrete type instead of the raw type-param `A`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@math3usmartins math3usmartins requested a review from a team June 14, 2026 01:10
@math3usmartins math3usmartins merged commit 508dd71 into main Jun 14, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant