Sirraide wrote: > I don't think an opt-in flag justifies the maintenance burden; I wouldn't > expect users to enable that flag by default (honestly, the folks who benefit > the most from the canonicalization are likely the same folks who would not > think to add a new flag to the command line to get that canonicalization). > > From a Windows perspective, Clang's current behavior is mildly infuriating > because it mixes path separators and not all tools handle that well. But it > is existing behavior that we've lived with forever, so it's not the end of > the world if we continue to not canonicalize paths. > > My weak preference is to consistently canonicalize all paths we want to > display to the user on the belief that the canonical path is the most useful > form for understanding what's being referenced. But if that's too disruptive > to change, I can live with the status quo too.
I mean, another option would be to add a separate flag to disable canonicalisation and enable it by default. I don’t think we want to canonicalise *all* paths though because e.g. `src/foo.cc` is less noisy than e.g. `/home/username/projects/whatever/src/foo.cc` (and we also have a flag for that already; it’s `-fdiagnostics-absolute-paths` or something like that). The point of this change imo (at least this was my original motivation), is to avoid printing excessively convoluted file paths, which is also why I originally added a check to use whichever path ends up being shorter (before or after canonicalisation). https://github.com/llvm/llvm-project/pull/148745 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
