================
@@ -184,14 +184,30 @@ GetAffectingModuleMaps(const Preprocessor &PP, Module
*RootModule) {
const SourceManager &SM = PP.getSourceManager();
const ModuleMap &MM = HS.getModuleMap();
- llvm::DenseSet<FileID> ModuleMaps;
-
- llvm::DenseSet<const Module *> ProcessedModules;
- auto CollectModuleMapsForHierarchy = [&](const Module *M) {
+ // Module maps used only by textual headers are special. Their FileID is
+ // non-affecting, but their FileEntry is (i.e. must be written as InputFile).
+ enum AffectedReason : bool {
+ ARTextualHeader = 0,
+ ARImportOrTextualHeader = 1,
+ };
+ auto AssignMostImportant = [](AffectedReason &L, AffectedReason R) {
+ L = std::max(L, R);
+ };
----------------
ilya-biryukov wrote:
I've updated to use `LHS` and `RHS`. However, I actually wanted to argue that
`L` and `R` are better choices for small functions. I have found that because
of the `HS` suffix, it is actually **easier** to confuse the two and misread
the code.
It usually does not matter, but if there's an error, it becomes harder to spot,
e.g.
```cpp
LHS.a < RHS.a && LHS.b < RHS.b && LHS.c < LHS.c && LHS.d < RHS.d
```
vs
```cpp
L.a < R.a && L.b < R.b && L.c < L.c && L.d < R.d
```
At least for me, the second variant stands out much more clearly.
That's the reason why I started using this pattern instead of the more common
LHS and RHS.
https://github.com/llvm/llvm-project/pull/116374
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
