Fix Windows module resolution for reserved path segments

[Copilot]

Windows module resolution failed when a path contained a reserved device-name segment such as con. This prevented declarations like the following from resolving:

export * from "./con/foo.js";

Changes

• Open Windows realpaths through the extended path namespace, preventing reserved components from being interpreted as devices.
• Preserve drive, UNC, and existing device-path handling.
• Add Windows regression coverage for both a con directory and a declaration file beneath it.

• Fixes Windows: module resolution fails for paths containing a con/ directory segment (reserved device name) #64653

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot address

[Daniel Rosenwasser (DanielRosenwasser)]

Won't this allocate a ton? Find another way or a mitigation.

[Copilot]

Copilot address

Addressed in be35d25. Ordinary paths now retain the original fast paths; an allocation-free component scan gates FullPath and prefix creation to reserved-name paths only. Added explicit zero-allocation coverage for the detector.

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot does it make sense to just try realpath and do the scan only if that doesn't work? It's extremely uncommon to have these device names.

[Copilot]

Copilot does it make sense to just try realpath and do the scan only if that doesn't work? It's extremely uncommon to have these device names.

Yes—updated in 196c2ef. The original short/long path open runs first; only a failure triggers the reserved-component scan and extended-path retry. Successful ordinary realpaths now pay no scan cost.

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot leave a comment because this is some extremely subtle and annoying behavior.

[Copilot]

Added in 03cdc4c. The comment explains the normal namespace's device-name interpretation, why the extended namespace works, and why detection is deferred until the ordinary open fails.

[Copilot]

🟢 Approval recommended

The implementation addresses the reported failure with focused Windows regression coverage and no identified correctness issues.

0 open findings

What changed in this PR

Fixes Windows realpath resolution for paths containing reserved device-name segments.

Changes:

• Retries failed realpath opens using extended Windows paths.
• Preserves drive, UNC, and device-path handling.
• Adds regression and reserved-name detection tests.

File	Description
tsc/​internal/​nativepath/​realpath_windows.go	Adds reserved-component detection and extended-path retry.
tsc/​internal/​nativepath/​realpath_windows_test.go	Tests reserved directories, files, detection, and allocations.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[Jake Bailey (jakebailey)]

This fails linting and testing

[Daniel Rosenwasser (DanielRosenwasser)]

Copilot address the issues. From CI:

=== FAIL: internal/nativepath TestRealpathReservedDeviceName (0.01s)
    realpath_windows_test.go:28: assertion failed: C:\Users\runneradmin\AppData\Local\Temp\TestRealpathReservedDeviceName1201972869\001\con (got string) != C:\Users\RUNNER~1\AppData\Local\Temp\TestRealpathReservedDeviceName1201972869\001\con (path string)

=== FAIL: internal/nativepath TestHasReservedPathComponent (0.00s)
panic: testing: AllocsPerRun called during parallel test [recovered, repanicked]

goroutine 4 [running]:
testing.tRunner.func1.2({0x7ff76eac1b20, 0x7ff76e80b0c0})
	C:/hostedtoolcache/windows/go-87ee608c/1.27.1/x64/src/testing/testing.go:2123 +0x239
testing.tRunner.func1()
	C:/hostedtoolcache/windows/go-87ee608c/1.27.1/x64/src/testing/testing.go:2126 +0x329
panic({0x7ff76eac1b20?, 0x7ff76e80b0c0?})
	C:/hostedtoolcache/windows/go-87ee608c/1.27.1/x64/src/runtime/panic.go:859 +0x125
testing.AllocsPerRun(0x64?, 0x3e4a2aa19f48?)
	C:/hostedtoolcache/windows/go-87ee608c/1.27.1/x64/src/testing/allocs.go:22 +0x1a5
github.com/microsoft/TypeScript/tsc/internal/nativepath.TestHasReservedPathComponent(0x3e4a2a7f8a00)
	D:/a/TypeScript/TypeScript/tsc/internal/nativepath/realpath_windows_test.go:53 +0x25a
testing.tRunner(0x3e4a2a7f8a00, 0x7ff76eb009e8)
	C:/hostedtoolcache/windows/go-87ee608c/1.27.1/x64/src/testing/testing.go:2193 +0xc3
created by testing.(*T).Run in goroutine 1

[Copilot]

Copilot address the issues. From CI:

Fixed the Windows short-path expectation, removed t.Parallel() from the allocation test, and adjusted cleanup to satisfy custom lint in 230869a.

[Jake Bailey (jakebailey)]

I don't think you can just remove Parallel without a nolint directive that says why