GeezerVison

Reviewed current head 1592d0b. The normal #375 case is fixed and the tests are green, but I found two path-handling cases that seem important to fix before merging.

One is a source path that goes through a symlink and then ... In that case cpplint can open one real file, while FileInfo.FullName() normalizes the path to a different lexical directory. The new same-directory header check can then look beside the wrong path. I reproduced both outcomes: it can warn even when the real sibling header exists, and it can suppress the warning when only an unrelated header exists in the normalized directory.

The other case is self-includes through filesystem aliases. If self.h includes alias.h and alias.h is a symlink or hard link to self.h, develop still reports build/include_subdir, but this PR suppresses it. os.path.samefile() confirms the two paths refer to the same file. The current normpath() / normcase() comparison only compares path strings, so it doesn't catch that identity case.

I also checked the ordinary same-directory behavior, missing headers, the sample-output changes, and the full test suite; those parts look good. I think these two filesystem cases should get regression tests and a fix before merge.

Re-reviewed current head d160830. Both findings from my previous review are fixed: I reproduced the symlink+.. false positive/false negative and both alias suppressions on 1592d0b, and all four behave correctly on this head.

The realpath/samefile change is narrowly scoped, the new regression tests fail without the corresponding fixes, and I also checked normal same-directory includes, self-includes, missing and invalid paths, symlinked sources, broken symlinks, and the fallback path handling without finding a new correctness issue.

Focused and full suites pass locally (236 tests, 96.48% coverage), along with pylint, mypy, pre-commit, and git diff --check.

No remaining blocker from me on this head. LGTM.

AI-assisted review of d160830. The full local suite passes (236 tests, Python 3.12/macOS), but I found a source-file symlink regression at cpplint.py:5859-5860.

With alias/main.cc -> physical/real.cc and #include "utils.hpp" in that source, Clang searches beside the supplied source pathname:

I reproduced this using clang++ -std=c++17 -fsyntax-only alias/main.cc and cpplint with --filter=-,+build/include_subdir. The second case is a new false negative: resolving the final source-file symlink makes an unrelated header suppress the diagnostic. The first is a remaining false positive.

Please resolve the parent directory for this lookup without dereferencing the final filename, while keeping the samefile self-include protection, and cover both header locations. A local experiment using realpath(dirname(filename)) restores both outcomes and passes the six existing include-path tests. This is distinct from the previously fixed directory-symlink-plus-.. case.