tristanlabelle wrote: Hi there, I'm the author of the original change.
> The whole point of **canonical** paths is to be unique for a given entity > (directory or file), so that they can be directly compared to determine > whether or not two entities are the same. I agree with that intended definition, but that is not the usage in practice. Code will arbitrarily canonicalize some paths and keep going, rather than using canonicalized paths only for comparisons. If I recall, we ended up with different clang output files (source map files?) encoding the same info but canonicalized inconsistently in a way that was not solvable. We need to use substitute drives to avoid `MAX_PATH` issues because llvm's build and test directories get very deep. `MAX_PATH` is a hopeless area of Windows programming. The "enable long paths" setting sounds like a silver bullet but it is not. It's not possible to set it in all environments since it's machine-wide, and it [only applies to applications declared to be long-path aware](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#registry-setting-to-enable-long-paths), which is not the norm. If I recall, the current implementation has issues, but they would be resolved by making it more low level: In the presence of chains of filesystem decorators, we'll undo the real-path mapping of the entire chain if it changes the drive, whereas we just want the real filesystem at the bottom of the chain to be decorated to avoid changing the drive. I would love this change to not be needed and for Windows to grow up regarding paths, but I fully expect things (at least lit tests) on Windows to break again if we revert it. https://github.com/llvm/llvm-project/pull/139739 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
