[all-commits] [llvm/llvm-project] 64d971: [include-cleaner] Unify symlink handling (#102615)

[kadir çetinkaya via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 64d9713637ab98e2b65c9c4317a50ddba0ba0dbc
      https://github.com/llvm/llvm-project/commit/64d9713637ab98e2b65c9c4317a50ddba0ba0dbc
  Author: kadir çetinkaya <kadircet at google.com>
  Date:   2024-08-13 (Tue, 13 Aug 2024)

  Changed paths:
    M clang-tools-extra/include-cleaner/include/clang-include-cleaner/Types.h
    M clang-tools-extra/include-cleaner/lib/Analysis.cpp
    M clang-tools-extra/include-cleaner/lib/HTMLReport.cpp
    M clang-tools-extra/include-cleaner/lib/Types.cpp
    M clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp
    M clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
    M clang-tools-extra/include-cleaner/unittests/IncludeSpellerTest.cpp
    M clang-tools-extra/include-cleaner/unittests/RecordTest.cpp

  Log Message:
  -----------
  [include-cleaner] Unify symlink handling (#102615)

We were using tryGetRealPathName in certain places, which resolves
symlinks (sometimes). This was resulting in discrepancies in behavior,
depending on how a file was first reached.

This path migrates all usages of tryGetRealPathName to regular getName
instead.

This implies one backward incompatible change for header-filtering. Our
ignore-header option used to filter against suffixes of absolute paths,
whereas now filter can receive working-directory relative paths in some
cases, possibly braking existing filters.
Chances of really braking users is pretty low:
- We'll still filter against absolute paths when header is outside the
  working directory (e.g. /usr/bin/include/some/linux/header.h.)
- Most projects run builds in a working directory that's nested inside
  the repository, hence relative paths still contain all the segments
  relative to repository root and anything else is unlikely to be
  meaningful. e.g. if a header is in
  `$HOME/work/llvm-project/clang-tools-extra/header.h` with builds being
  run in `$home/work/llvm-project/build`, we'll still filter against
  `../clang-tools-extra/header.h` which has all the useful segments as a
  suffix.
- This is also a change in how we handle symlinks, but this is aligned
  with what we do in rest of our tools (clangd, tidy checks etc.). We
  tend to not resolve any symlinks for the file.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications