Inconsistent path handling results in miscompilation on Windows systems

[xaberus]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.74.0+
• OS Version: Windows 10

Steps to Reproduce:

1. yarn --frozen-lockfile
2. yarn gulp compile-build

On Windows systems the data.path field in

vscode/build/lib/compilation.ts

Line 130 in 70c45ba

const newContents = newContentsByFileName.get(data.path);

is \ separated but the TS compiler that generates the newContentsByFileName map uses / slashes. Therefore none of the replacements done by the mangler are found.

In the context of the remote extension hosts this leads to problems when the Windows built Windows client connects to, i.e., a Linux built Linux client. Names of private fields leak in the JSON.stringify() serialization in

vscode/src/vs/workbench/services/extensions/common/remoteExtensionHost.ts

Line 160 in 612d2c8

protocol.send(VSBuffer.fromString(JSON.stringify(data)));

and cause surprising bugs. (These bugs are VSCode-OSS specific even though they are filled against VSCodium).

A possible solution can be found here: VSCodium/vscodium#1370

[VSCodeTriageBot]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.2. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[xaberus]

The issue exists in all releases newer than 1.73.1.

[jrieken]

Thanks. This is a great find. At first I will fix the pipeline scripts, second we will think about the fact that serialization depends on private object state

[jrieken]

fyi @alexdima This is about ExtensionIdentifier and potentially others. The _lower property will be mangled at build times and if that happens unequally* the toKey function fails.

^* As of today this bug is the only case where unequal mangling happens, the names are generated in a deterministic fashion and for types that aren't involved in inheritance things are simple. Tho, we might wanna implement toJSON explicitly or mark the field as public

[jeanp413]

@jrieken created a PR #172739 fixing the bug reported in this comment

[jrieken]

Thanks @jeanp413