Skip to content

feat: parse call/construct/index signatures in type literals & class bodies (#121)#124

Merged
nickna merged 1 commit into
mainfrom
feature/issue-121-type-literal-signatures
Jun 6, 2026
Merged

feat: parse call/construct/index signatures in type literals & class bodies (#121)#124
nickna merged 1 commit into
mainfrom
feature/issue-121-type-literal-signatures

Conversation

@nickna
Copy link
Copy Markdown
Owner

@nickna nickna commented Jun 6, 2026

Closes #121.

The interface parser already handled call/construct/index signatures, but two other parser sites did not — which is where the conformance assignmentCompatibility tests were dying as ParseError.

Gap A — inline object type literals

Parser.Types.cs (ParseInlineObjectType) + TypeChecker.TypeParsing.cs (ParseInlineObjectTypeInfo):

  • { (x: number): void } — bare call signature
  • { new (x): T } — construct signature
  • { readonly p: T } — readonly member modifier

A pure single call-signature object type resolves to a real function type (TypeInfo.Function) and type-checks against function types correctly. Mixed/overloaded/construct cases reach the checker as a Record (signatures dropped, not modeled yet — see follow-up #122).

Gap B — class-body index signatures

Parser.Classes.cs:

Baseline movement

types/conditional + assignmentCompatibility subset:

54 ParseError / 15 Fail / 10 Pass49 ParseError / 18 Fail / 12 Pass

5 tests off ParseError (2 new passes, 3 now reaching the type checker). Both new passes verified legitimate (no *.errors.txt baseline → valid no-error tests).

Verification

  • All repros parse and type-check (call-sig object types behave as function types).
  • TS conformance suite green (31/31); baseline regenerated.
  • Core xUnit suite: 10341/10344. The 3 failures (web-streams AbortSignal, NuGet packaging) fail identically on clean main — pre-existing/environmental, unrelated to this change.

Follow-ups

…bodies (#121)

The interface parser already handles call signatures, construct signatures,
and index signatures, but two other parser sites did not — which is where
the conformance assignmentCompatibility tests were dying as ParseError.

Gap A — inline object type literals (Parser.Types.cs ParseInlineObjectType):
  - `{ (x: number): void }`  — bare call signature
  - `{ new (x): T }`         — construct signature
  - `{ readonly p: T }`      — readonly member modifier
  ParseInlineObjectTypeInfo recognizes the emitted bare-signature members so
  they no longer mis-resolve into bogus fields; a pure single call-signature
  object type resolves to a function type (TypeInfo.Function) and type-checks
  against function types correctly. Mixed/overloaded/construct cases reach the
  checker as a Record (signatures dropped, not modeled yet).

Gap B — class-body index signatures (Parser.Classes.cs):
  - `class A { [x: string]: T }` — disambiguated from a computed property name
    ([expr]:) by an identifier immediately followed by ':'. Parsed so the class
    body no longer ParseErrors; modeling the index type on the class type is
    deferred.

Baseline (types/conditional + assignmentCompatibility subset):
  54 ParseError / 15 Fail / 10 Pass -> 49 ParseError / 18 Fail / 12 Pass
  (5 tests off ParseError: 2 new passes, 3 now reaching the type checker).
  Conformance suite green (31/31); no regressions in the core xUnit suite.
@nickna nickna merged commit 8832c9f into main Jun 6, 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.

TS Conformance: parse call/construct/index signatures in type literals & class bodies (#119 follow-up)

1 participant