[clang] [clang][ExtractAPI] Ensure LocationFileChecker doesn't try to traverse VFS when determining file path (PR #74071)
tristanlabelle wrote: @daniel-grumberg It's me. I'm looking at this https://github.com/llvm/llvm-project/pull/74071 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][ExtractAPI] Ensure LocationFileChecker doesn't try to traverse VFS when determining file path (PR #74071)
https://github.com/tristanlabelle approved this pull request. Looks good, thanks for catching this. https://github.com/llvm/llvm-project/pull/74071 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Revert "[lit][clang] Avoid realpath on Windows due to MAX_PATH limitations" (PR #139739)
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
[clang] [llvm] Revert "[lit][clang] Avoid realpath on Windows due to MAX_PATH limitations" (PR #139739)
tristanlabelle wrote: Hi @michael-jabbour-sonarsource , thanks for the ping! I agree with your views on how canonicalization should be defined and work in theory, but I am concerned about reconciliating it with the reality that: 1. Code pervasively access files through canonicalized paths rather than using canonicalized paths only for identity comparisons. The two usages are often conflated and can't be teased apart easily. 2. Hitting the Windows `MAX_PATH` limitation is a showstopper (broken builds or tests) I don't think higher-level workarounds are possible (in APIs or in tests) because there is information loss once the lower levels have performed canonicalization, and lower levels can perform file accesses on paths that they have canonicalized. I wish I had more alternatives to offer :/ 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
