Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Checker: CheckModules retains diagnostics when reused for a new program

Closed Beginner friendly
  • Is something wrong?
#2,440 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
compilers

Research direction

Start in the TypeChecker class and compare CheckModules with CheckWithRecovery, which clears _diagnostics at entry while CheckModules does not. Reproduce with the two-script sequence in the issue: check the invalid file, then the valid one on the same checker, and inspect GetDiagnostics(). Done means the second CheckModules call reports only its own program's diagnostics, matching a fresh checker, and the TS2322 from the first run no longer appears.

Written by the indexing model from the issue text.

Description

TypeChecker.CheckModules retains diagnostics from a previous program when the same checker is reused.

Create one TypeChecker(strictNullChecks: true, maxErrors: 20), then check two independent script ParsedModules in sequence:

// first-invalid.ts
const value: number = "bad";

// second-valid.ts
const value: number = 1;

The first run correctly reports TS2322. After checking the second program, GetDiagnostics() still returns the identical TS2322, including the first program's file path and message. A fresh checker checking the same second program returns no diagnostics. Strict TypeScript rejects the first source and accepts the second.

The probe only calls the public checker API: parse with Lexer/Parser; create ParsedModule(path, statements) { IsScript = true }; call CheckModules([module], new ModuleResolver(directory)); snapshot GetDiagnostics(). No guest source is evaluated or emitted.

Reproduce with the retained-only .NET probe:

dotnet artifacts/issue-work-2116-2218/2169/review-controls/diagnostic-reuse-probe/bin/Debug/net10.0/DiagnosticReuseProbe.dll artifacts/issue-work-2116-2218/2169/review-controls artifacts/issue-work-2116-2218/2169/before-runtime-931e/SharpTS.dll

Both the retained assembly and the copied assembly actually loaded by the probe have SHA256 931E79A72E63F9A04F1D75D2F83B25E67A0178CB99843B827847404EA119DC84, built from source committed as 17041ec6c before #2169 work. No introducing-commit claim is made. CheckWithRecovery clears _diagnostics at entry; CheckModules lacks the corresponding fresh-program reset.

Evidence: artifacts/issue-work-2116-2218/2169/review-controls/diagnostic-reuse-report.json, the retained-only probe project/source, exact input sources and strict TypeScript logs. The report pins both assembly hashes, source hashes and all three diagnostic snapshots.

Fresh all-state dedup searched CheckModules diagnostics, reused checker diagnostics, stale diagnostics and checker diagnostic clear. Closed #1226 concerns ignoring checker diagnostics in a harness, and #1975 concerns versioned editor snapshots; neither owns diagnostic retention between separate public CheckModules calls. Search evidence is diagnostic-reuse-dedup.json beside the report.

Dominant language
C#
Stars
156
Forks
4
Avg merge
5h 34m
Merged PRs (30d)
51

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.