Fix data races that corrupted concurrent conversions

[paulirwin]

Fixes the intermittent test failures noted in #159.

JavaToCSharp was not safe to call concurrently. This affects real consumers converting files in parallel, and it was also causing flaky CI: roughly 1 run in 10 failed, in a different test class each time.

The bug

TypeNameParser was a static class holding its entire recursive-descent parse state in static fields — including a shared StringBuilder:

private static (string, TokenType)[]? _tokens;
private static (string text, TokenType type) _token;
private static int _currentIndex;
private static readonly StringBuilder _sb = new();

ConvertType is on the hot path of essentially every conversion, and xUnit runs test classes in parallel. Two conversions interleaving _sb.Clear() / _sb.Append() splice each other's output — the symptom that led me here was generated code containing:

public static voidvoid Main(string[] args)

The return type emitted twice. Concurrent mutation of the shared token array and index can also throw IndexOutOfRangeException outright, which is what the new test hits first against the old code.

The fix

• TypeNameParser is now an instance class, constructed fresh per ParseTypeName call, so no parse state is shared. The public entry point is unchanged — this is not a breaking change.
• TypeHelper._typeNameConversions is now a ConcurrentDictionary. It's mutated during conversion by ClassOrInterfaceDeclarationVisitor (registering interface renames when StartInterfaceNamesWithI is set) while other threads read it in ConvertType — undefined behavior for Dictionary<,>.
• Dropped two now-dead defensive checks: _tokens is always assigned in the constructor, and _translate?.Invoke(...) was silently appending an empty string on null rather than failing.

Testing

New ConcurrencyTests covers parallel ConvertType calls and parallel end-to-end conversions. I verified these are genuine regression tests: both fail reliably against the old code (stashed the fix and confirmed) and pass with it.

Full suite run 15 consecutive times: 286/286 passing every time. On master the same loop reproduces a failure within ~10 runs.

Note on scope

TypeHelper._typeNameConversions being process-global mutable state is still a design smell — per-file class renames leak between conversions, so converting two files with StartInterfaceNamesWithI can bleed one file's renames into the other. The proper fix is moving it onto ConversionContext, but ConvertType has ~60 call sites and is public API used directly by tests, so that's a larger breaking change. This PR makes it safe without changing the API; happy to do the deeper refactor separately if you want it.

🤖 Generated with Claude Code