llvm-project

5710e418 - [DTLTO][Windows] Expand short 8.3 form paths in ThinLTO module IDs (#178303)

[DTLTO][Windows] Expand short 8.3 form paths in ThinLTO module IDs (#178303) Windows supports short 8.3 form filenames (e.g. `compile_commands.json` -> `COMPIL~1.JSO`) for legacy reasons. See: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#short-vs-long-names. Short 8.3 form paths are undesirable in distributed compilation scenarios because they are local mappings tied to a specific directory layout on a specific machine. As a result, they can break or defeat sandboxing and path-based isolation mechanisms used by distributed build systems. We have observed such failures with DTLTO even in simple scenarios. For example, on Windows, running: ``` clang.exe hello.c -flto=thin -fuse-ld=lld -fthinlto-distributor=fastbuild.exe -### ``` on my development machine reveals a short 8.3 form path being passed to LLD (output paraphrased): ``` ld.lld -o a.out -plugin-opt=thinlto --thinlto-distributor=fastbuild.exe \ --thinlto-remote-compiler=clang.exe C:\Users\DUNBOB~1\AppData\Local\Temp\hello-380d65.o ``` This behavior occurs because, on Windows, the system temporary directory is commonly derived from the `TMP`/`TEMP` environment variables. For historical compatibility reasons, these variables are often set to short 8.3 form paths, particularly on systems where user names exceed eight characters. Whilst it's possible for users to work around these issues, in practice, especially in automated and CI environments, users often have limited control over their environment. DTLTO generally tries to avoid embedding distribution-specific logic in the LLVM source tree, and this principle also applies to path normalization. However, on Windows, such short 8.3 form paths are undesirable for any distribution system. This normalization also cannot be delegated to distributors, as the ThinLTO module ID must be finalized early during LTO and cannot be modified later. Given this, normalizing away short 8.3 paths on Windows is a pragmatic, targeted improvement, even though path normalization is not something a toolchain would typically perform in the general case. SIE internal tracker: TOOLCHAIN-19185