Breakpoint paths sent to the VM are case-sensitive on Windows

[DanTup]

I suspect this is a can of worms, but I was investigating a bug with breakpoints not being hit today (Dart-Code/Dart-Code#586) and it turned out to be related to the casing of drive letters.

The drive letter that the VM is deciding is correct for the drive is different to the one that my editor is providing me as a breakpoint path. This causes the breakpoint to be missed. I have a dirty workaround, which is to always send breakpoints with both a lowercase and uppercase drive letter:

if (isWin) {
	// Flip the casing of the drive letter since it's often different and the VM doesn't
	// consider then the same.
	uris.slice().forEach((uri) => {
		// If the drive letter is lowercase, add an uppercase version.
		if (uri.startsWith("/") && uri.substring(1, 2) === uri.substring(1, 2).toLowerCase())
			uris.push("/" + uri.substring(1, 2).toUpperCase() + uri.substring(2));
		// If the drive letter is uppercase, add an uppercase version.
		if (uri.startsWith("/") && uri.substring(1, 2) === uri.substring(1, 2).toUpperCase())
			uris.push("/" + uri.substring(1, 2).toLowerCase() + uri.substring(2));
	});
}

However, this seems a bit fragile - I'm sure in future someone will manage to have some other part of the path cased differently and we'll see a similar bug.

Since I can't influence the casing of the URI inside the VM, I wonder if the the best fix would be for the VM to treat file:/// URIs as case-insensitive on Windows?

(We have a similar issue with the analyzer #32095 so I suspect inconsistencies with Windows reported casing of drive letters might spread quite far!)

[DanTup]

@bkonyi this came up again at Dart-Code/Dart-Code#3796 from a user using Emacs which uses the Dart-Code debug adapter (which will likely migrate to the SDK adapter). Specifically, the different casing of the drive letter is causing the issue.

For VS Code, we normalise all drive letters to uppercase in the client, but that means other clients don't have the fix. We could move the normalisation into the debug adapter to handle it for all (DAP) clients although I wonder if it's going to end up in the SDK for it to be handled in the VM instead (so non-DAP clients would also get the benefit, like DevTools/IntelliJ?).

I've no idea of the scale of the issue though. In theory there can be case-sensitive volumes on Windows, and current macOS is also case-insensitive, so it's not just a platform thing (and perhaps things are even more confusing if you're developing on Windows and the VM is running on a mobile device running Android...)