aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Lex/ModuleMap.cpp
diff options
context:
space:
mode:
authorJan Svoboda <jan_svoboda@apple.com>2023-07-06 19:07:04 +0200
committerJan Svoboda <jan_svoboda@apple.com>2023-07-17 13:50:24 -0700
commitbe014563f2f492658abcfa68cfaffc58a4ed7d9a (patch)
tree4745e124865c09c843cb913392fe242e1390d6a9 /clang/lib/Lex/ModuleMap.cpp
parent227f71995804fa5df3f917ae3a7b1499cd24726c (diff)
downloadllvm-be014563f2f492658abcfa68cfaffc58a4ed7d9a.zip
llvm-be014563f2f492658abcfa68cfaffc58a4ed7d9a.tar.gz
llvm-be014563f2f492658abcfa68cfaffc58a4ed7d9a.tar.bz2
[clang][modules][deps] Parse "FW_Private" module map even after loading "FW" PCM
When Clang loads a PCM that depends on another PCM describing framework module "FW", `ModuleMap` registers "FW" as known, without seeing the module map that defines it (or the adjacent "FW_Private" module map). Later, when looking at a header from "FW_Private", `ModuleMap` returns early due to having knowledge about "FW" and never associates that header with "FW_Private", leading to it being treated as textual. This behavior is caused by D150292, where the scanner stops calling `HeaderSearch::lookupModule()` eagerly for every loaded PCM. This patch skips an early check when trying to figure out the framework module for a header, which ensures the "FW" and (most importantly) "FW_Private" module maps can be parsed even after loading "FW" from a PCM. Note that the `HeaderSearch::loadModuleMapFile()` function we not call unconditionally has caching behavior of its own, meaning it will avoid parsing module map file repeatedly. Depends on D150320. Reviewed By: benlangmuir Differential Revision: https://reviews.llvm.org/D150478
Diffstat (limited to 'clang/lib/Lex/ModuleMap.cpp')
0 files changed, 0 insertions, 0 deletions