Repository navigation
fix: source file paths are normalized - #1318
Open
gennaroprota wants to merge 1 commit into
Open
gennaroprota wants to merge 1 commit into
gennaroprota wants to merge 1 commit into
Conversation
Contributor
✨ Highlights
🧾 Changes by Scope
🔝 Top Files
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1318 +/- ##
===========================================
+ Coverage 83.12% 83.21% +0.09%
===========================================
Files 35 35
Lines 3662 3670 +8
Branches 844 845 +1
===========================================
+ Hits 3044 3054 +10
Misses 410 410
+ Partials 208 206 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
An automated preview of the documentation is available at https://1318.mrdocs.prtest2.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-10-14 14:28:28 UTC |
gennaroprota
force-pushed
the
fix/source_file_paths_are_normalized
branch
from
October 14, 2026 11:07
2f893bf to
d4c1728
Compare
This fixes a bug for which an include file reached from an input directory through e.g. `#include "../vendor/x.hpp"` was taken to lie inside that directory. Its symbols were documented as the project's own, `exclude` could not reach it, and its path read api/../vendor/x.hpp. The compiler records the includer's directory joined with what the include spells out, ".." and all. Such an unnormalized path was normalized when the compiler recorded it as relative, on its way to being made absolute, but not when it recorded it as absolute, as it does for a header found through an absolute include directory and for every file of a compilation database, including the one synthesized from the configuration. We now normalize it there, too, unless the result names another file, which happens on POSIX when a symlinked directory comes before the "..": that path is kept as written, as before. We also normalize the include directories and the source root that a path is shortened against, so that they still match it as text. I've added tests. Note that the reference of a project that reaches include files through ".." can change: symbols from such files outside `input` are no longer documented, `exclude` now applies to them, their paths are shown normalized, and macros defined in them get new IDs. This holds for every absolute path the compiler records, including that of a main file listed in a compilation database. Note that an absolute `exclude` entry containing ".." no longer matches the files under it, because we normalize the file paths but not such an entry.
gennaroprota
force-pushed
the
fix/source_file_paths_are_normalized
branch
from
October 14, 2026 14:18
d4c1728 to
62e398c
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes a bug for which an include file reached from an input directory through e.g.
#include "../vendor/x.hpp"was taken to lie inside that directory. Its symbols were documented as the project's own,excludecould not reach it, and its path read api/../vendor/x.hpp.The compiler records the includer's directory joined with what the include spells out, ".." and all. Such an unnormalized path was normalized when the compiler recorded it as relative, on its way to being made absolute, but not when it recorded it as absolute, as it does for a header found through an absolute include directory and for every file of a compilation database, including the one synthesized from the configuration. This normalizes it there, too. The normalization is lexical, like the one already applied to relative paths, so it resolves no symlinks. It is skipped when the normalized path names another file than the one the compiler opened, which happens on POSIX when a symlinked directory comes before the "..", and such a path is kept as written, as before. The include directories and the source root a path is shortened against are normalized the same way, so they still match it as text.
This narrows the "as written" rule that
excludefollowed so far to "not symlink-resolved":excludenow matches the file path once "." and ".." are removed, and still does not resolve symlinks.Changes
ASTVisitor::buildFileInfonormalizes a source file path the compiler recorded as absolute when the result names the same file, as it already did for one recorded as relative, and normalizes the directories it shortens paths against.excludeand once with a narrowerinput. Unit tests build a real corpus over a temporary tree, one for an include file outside the inputs and one for an include file inside an exclusion.inputthat were documented by mistake disappear,excludenow applies to such files, their paths are shown normalized, and macros defined in them get new IDs and links. This holds for every absolute source path the compiler records, including main files listed in a compilation database. An absoluteexcludeentry that contains ".." no longer matches the files under it, because file paths are now normalized and such an entry is not (a relative entry is); normalizing absolute path options is left for a follow-up.Testing
The golden fixture tests/golden/fixtures/filters/file/unnormalized-path shows the vendored header at vendor/vendored.hpp when nothing filters it, and drops it under
excludeand under a narrowerinput; all three outputs differ without the fix. tests/unit/AST/FileFilters.cpp addstestUnnormalizedPathOutsideTheInputsandtestUnnormalizedPathInsideAnExclusion, which go through the database synthesized from the configuration, and both fail without the fix. No existing golden output changes.The symlink case has no test: it needs a symlinked directory, which a Windows checkout without symlink support cannot create. FileFilters.cpp carries a third copy of the
writeFilehelper of the script and data-driven generator tests; consolidating them is left for a follow-up.Documentation
The
excludeoption now says that it matches the file path once "." and ".." are removed, and that an absolute entry is used as written, so it should not contain "." or "..".inputneeds no change: it selects "files in these directories", which is what it now does for an include file reached through "..".