It turns out several Chromium developers rely on this on Windows.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/clang/Driver/CLCompatOptions.td | ||
---|---|---|
68 ↗ | (On Diff #69045) | Hm, I'm not sure this should affect FILE. It sounds people want this for diagnostics, but making it affect FILE makes reproducible builds harder. (There's -ffile-macro-prefix-to-remove from http://reviews.llvm.org/D17741 for that too, but that's not in.) |
include/clang/Driver/CLCompatOptions.td | ||
---|---|---|
68 ↗ | (On Diff #69045) | The MSVC docs say it applies to FILE though https://msdn.microsoft.com/en-us/library/027c4t2s.aspx and I worry that implementing only half of it might surprise users. Chromium currently builds with MSVC and /FC, so we should already have full paths in FILE there. |
include/clang/Driver/CLCompatOptions.td | ||
---|---|---|
68 ↗ | (On Diff #69045) | Sure, but the MSVC build is not deterministic in several ways that folks aren't happy about, and we're supposed to improve that :-) As far as I know FILE defaults to just the file's basename in cl.exe (is that true?). So without /FC FILE is useless there and people more or less have to pass /FC. With clang, we emit the full relative path to the file, so it's not useless already. For diagnostics, I can kind of see how full paths are useful: You likely develop on the same machine as you see the diagnostics on, so people want real absolute paths so they can click on them in MSVC. For FILE, that's less convincing, since that gets embedded into the binary that's shipped elsewhere. |
include/clang/Driver/CLCompatOptions.td | ||
---|---|---|
68 ↗ | (On Diff #69045) |
In my testing, MSVC does include the full relative path in FILE by default. I agree that diagnostics seems to be the main motivation here. I'm just worried that if we implement /FC but leave out the FILE part, that's confusing for whoever might rely on it. Maybe we should just do an -fabs-path-diagnostics option instead? |
include/clang/Driver/CLCompatOptions.td | ||
---|---|---|
68 ↗ | (On Diff #69045) | Works for me :-) |
include/clang/Driver/Options.td | ||
---|---|---|
994 ↗ | (On Diff #69300) | How about -fdiagnostics-[use-]absolute-paths rather than -fdiagnostics-abs-path to avoid any confusion about this referring to the abs function? |
lib/Frontend/TextDiagnostic.cpp | ||
773 ↗ | (On Diff #69300) | Err, setting the second parameter to true here causes it to generate incorrect paths. I wouldn't do that... If you want to remove .. components, you should use FileManager::getCanonicalName instead, which will do the appropriate symlink resolution here. |
include/clang/Driver/Options.td | ||
---|---|---|
994 ↗ | (On Diff #69300) | Sounds good to me. |
lib/Frontend/TextDiagnostic.cpp | ||
---|---|---|
770–777 ↗ | (On Diff #69304) | Why split off the filename and rejoin it here? Is this to better handle cases where the directory exists but the file doesn't, or an attempt to avoid resolving file symlinks? A comment in the code explaining this would be useful. |
lib/Frontend/TextDiagnostic.cpp | ||
---|---|---|
770–777 ↗ | (On Diff #69304) | If I understand correctly, getCanonicalName only works with a DirectoryEntry, which is supposed to be a directory, not a full path to a file. So I didn't see any other way than getting the canonical name for the dir, and then joining it with the filename. |