[clang][dataflow] Disambiguate a ref to "internal" in CachedConstAccessorsLattice

[jvoung]

Disambiguate to fix a build error (e.g., on windows with clang-cl)

[llvmbot]

@llvm/pr-subscribers-clang-analysis

Author: Jan Voung (jvoung)

Changes

Disambiguate to fix a build error (e.g., on windows with clang-cl)

---

Full diff: https://github.com/llvm/llvm-project/pull/113601.diff

1 Files Affected:

• (modified) clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h (+4-3)

diff --git a/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h b/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
index 3402d105746e88..48c5287367739a 100644
--- a/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
+++ b/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
@@ -154,11 +154,12 @@ LatticeEffect CachedConstAccessorsLattice<Base>::join(
   // are non-identical but equivalent. This is likely to be sufficient in
   // practice, and it reduces implementation complexity considerably.
 
-  ConstMethodReturnValues = internal::joinConstMethodMap<Value>(
-      ConstMethodReturnValues, Other.ConstMethodReturnValues, Effect);
+  ConstMethodReturnValues =
+      clang::dataflow::internal::joinConstMethodMap<dataflow::Value>(
+          ConstMethodReturnValues, Other.ConstMethodReturnValues, Effect);
 
   ConstMethodReturnStorageLocations =
-      internal::joinConstMethodMap<StorageLocation>(
+      clang::dataflow::internal::joinConstMethodMap<dataflow::StorageLocation>(
           ConstMethodReturnStorageLocations,
           Other.ConstMethodReturnStorageLocations, Effect);
 

[llvmbot]

@llvm/pr-subscribers-clang

Author: Jan Voung (jvoung)

Changes

Disambiguate to fix a build error (e.g., on windows with clang-cl)

---

Full diff: https://github.com/llvm/llvm-project/pull/113601.diff

1 Files Affected:

• (modified) clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h (+4-3)

diff --git a/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h b/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
index 3402d105746e88..48c5287367739a 100644
--- a/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
+++ b/clang/include/clang/Analysis/FlowSensitive/CachedConstAccessorsLattice.h
@@ -154,11 +154,12 @@ LatticeEffect CachedConstAccessorsLattice<Base>::join(
   // are non-identical but equivalent. This is likely to be sufficient in
   // practice, and it reduces implementation complexity considerably.
 
-  ConstMethodReturnValues = internal::joinConstMethodMap<Value>(
-      ConstMethodReturnValues, Other.ConstMethodReturnValues, Effect);
+  ConstMethodReturnValues =
+      clang::dataflow::internal::joinConstMethodMap<dataflow::Value>(
+          ConstMethodReturnValues, Other.ConstMethodReturnValues, Effect);
 
   ConstMethodReturnStorageLocations =
-      internal::joinConstMethodMap<StorageLocation>(
+      clang::dataflow::internal::joinConstMethodMap<dataflow::StorageLocation>(
           ConstMethodReturnStorageLocations,
           Other.ConstMethodReturnStorageLocations, Effect);
 

[nico]

I think this'll fix the build, thanks!

However, the root cause is probably that the AST_MATCHER_P_OVERLOAD instantiation in clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp is in an unnamed namespace that's inside namespace clang::dataflow, right? Should we move that to just an unnamed namespace at the top of that file that isn't in clang::dataflow?

[jvoung]

AST_MATCHER_P_OVERLOAD

Ah, missed the part where the macro is generating the internal namespaces. I don't think we want to move to the top of the file exactly (the instantiation refers to some functions defined right above, so would need fwd decls?), but we can change the namespacing inline } ... {.

There seem to be other recommendations in the header

llvm-project/clang/include/clang/ASTMatchers/ASTMatchersMacros.h

Line 26 in 6854ad9

// namespace my_matchers {

like putting in clang::ast_matchers::unnamed... (though I'm not sure if they mean exactly clang::ast_matchers.

Let me try and check with the team.