[all-commits] [llvm/llvm-project] 1e10f9: [clang][Lex] Collapse relative extern module paths...

[Tom Murray via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1e10f9a8222227ad665a1b9cd73ed27f5bc21845
      https://github.com/llvm/llvm-project/commit/1e10f9a8222227ad665a1b9cd73ed27f5bc21845
  Author: Tom Murray <TomMurray at users.noreply.github.com>
  Date:   2026-04-29 (Wed, 29 Apr 2026)

  Changed paths:
    M clang/lib/Lex/ModuleMap.cpp
    M clang/unittests/Lex/CMakeLists.txt
    A clang/unittests/Lex/ModuleMapTest.cpp

  Log Message:
  -----------
  [clang][Lex] Collapse relative extern module paths when recursing to prevent unbounded path length growth. (#193691)

Ref #147220.

### Problem Description
Bazel's use of clang modules for its `layering_check` emits `extern
module` declarations relative to some base path meaning those paths
usually include long sequences of `../` followed by the path to the
module itself.

When parsing `extern module` in the module file, we (I believe
intentionally) silently ignore missing module files. Currently in the
problem case if the file existence check failed for any _other_ reason
it also silently ignores it. This means that `-fmodules-strict-decluse`
that bazel uses for the layering_check can throw a spurious
`err_undeclared_use_of_module` error which is the problem reported in
#147220.

Clang's `extern module` parsing chooses to concatenate these relative
paths recursively meaning the growth in those paths is unbounded. In
this case the file existence check fails due to the path name being too
long (ENAMETOOLONG in POSIX).

In summary there are possibly 2 underlying problems that contribute to
#147220 that we could try to fix:
1. Silently ignoring unexpected errors (ENAMETOOLONG) meaning the
ultimately reported error (undeclared use of module) doesn't really help
the user understand what was wrong.
2. Unbounded path growth when recursively declaring `extern module`s in
a chain.

I'm choosing to focus on (2) in this PR because both fixes seem useful,
and (1) seems an intentional design choice.

### Implementation
Collapse `../` in relative `extern module` paths before loading those
modules for parsing.



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