[clang] [clang-repl] fix CleanUpPTU by removing decl according to C implicitly FuncitonDecl. (PR #178648)

[via cfe-commits]

================
@@ -182,6 +183,30 @@ void IncrementalParser::CleanUpPTU(TranslationUnitDecl *MostRecentTU) {
     }
   }
 
+  auto *ECCD = S.getASTContext().getExternCContextDecl();
+  if (auto *Map = ECCD->getPrimaryContext()->getLookupPtr()) {
+    for (auto &&[Key, List] : *Map) {
+      DeclContextLookupResult R = List.getLookupResult();
+      std::vector<NamedDecl *> NamedDeclsToRemove;
+      for (NamedDecl *D : R) {
+        // Implicitly generated C decl is not attached to the current TU but
+        // lexically attached to the recent TU, so we need to check the lexical
+        // context.
----------------
fogsong233 wrote:

I have not found a direct O(1) method to retrieve it. Because an implicit declaration may not be a direct child of the Translation Unit (TU), and it is semantically attached to an extern "C" context. Consequently, we must remove it from that specific context, which requires traversing the lookup table—a process similar to traversing getMostRecentDecl. 
Or if we want O(1) access, alternatively we could introduce a new data structure where the implicit function is created. However, it would need to distinguish whether the implicit declaration occurred before or after the current TU, which may not be ideal.
> If there is no way to get it, then there is some logical flow in either clang, where the implicit declaration creation does not respect the active TU or something else.

The C implicit declaration is looked up by the extern "C" declaration. However, if we want to remove all declarations during this PTU, we cannot get the name. In my view, I think this traversal is good enough:
- First, it won't change clang's code. 
- Besides, C implicit declarations are very rare, as they would be seen as errors in normal cases. Therefore, there are probably only C implicit declarations within this PTU, so there actually aren't many. This is more like a corner case rather than something that would trigger traversals frequently :)

https://github.com/llvm/llvm-project/pull/178648