[clang][Tooling] Move STL recognizer to its own library

[kadircet]

Summary

As pointed out in https://reviews.llvm.org/D119130#3829816, this
introduces a clang AST dependency to the clangToolingInclusions, which is used
by clang-format.

Since rest of the inclusion tooling doesn't depend on clang ast, moving this
into a separate library.

[sammccall]

clang-tools-extra/clangd/CMakeLists.txt

163

StandardLibrary or Stdlib?

STL isn't accurate or consistent with the names in the code.

clang/lib/Tooling/Inclusions/STL/CMakeLists.txt

2 ↗

(On Diff #465306)

This means the implementation files and the header files have a different directory structure, which may be confusing to people trying to work out which library to link against based on the headers they included.

On the other hand, I think the cascading effect of dependencies => libraries => directory structure => header structure is pretty unfortunate leaking of llvm's sad cmake structure. Up to you

[kadircet]

clang-tools-extra/clangd/CMakeLists.txt

163

changing to Stdlib

clang/lib/Tooling/Inclusions/STL/CMakeLists.txt

2 ↗

(On Diff #465306)

right, i was also torn between moving the headers around vs not. but i finally managed to convince myself that the implementation being in a different subdirectory is actually an unfortunate detail about the way LLVM is build (I didn't want to have PARTIAL_SOURCES_INTENDED, either) and shouldn't matter for the applications that want to use it.

[kadircet]

• Rename STL to Stdlib

[thakis]

Thanks!

clang/lib/Tooling/Inclusions/STL/CMakeLists.txt

2 ↗

(On Diff #465306)

FWIW, I'd move the header.

FWIW, I also don't think llvm's cmake setup is particularly unfortunate here either. It makes it easy to see where library boundaries are.

[thakis]

(Alternatively, it looks like the only client is clangd, so maybe the file could just live in there instead of being in a dedicated library with a single client.)

[kamaub]

This change causes a linking failure during the check-all testing of 'clang-tools-extra' on the clang-ppc64le-rhel #22596 and clang-ppc64le-linux-multistage #23864 build bots, please address this failure as soon as possible.

[kadircet]

sorry for that, bb4f0af97dba600c50a0f727b25a760e8185c578 should fix it

clang-tools-extra/clangd/CMakeLists.txt

clang_target_link_libraries(clangDaemon
   clangFrontend
   clangIndex
   clangLex
   clangSema
   clangSerialization
   clangTooling
   clangToolingCore
   clangToolingInclusions
+  clangToolingInclusionsStdlib
   clangToolingSyntax
   )
 
 target_link_libraries(clangDaemon
   PRIVATE
   ${LLVM_PTHREAD_LIB}
 
   clangTidy

clang/lib/Tooling/Inclusions/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangToolingInclusions
   HeaderIncludes.cpp
   IncludeStyle.cpp
-  StandardLibrary.cpp
 
   LINK_LIBS
-  clangAST
   clangBasic
   clangLex
   clangRewrite
   clangToolingCore
   )
+
+  add_subdirectory(Stdlib)

clang/lib/Tooling/Inclusions/Stdlib/CMakeLists.txt

+add_clang_library(clangToolingInclusionsStdlib
+  StandardLibrary.cpp
+
+  LINK_LIBS
+  clangAST
+  )

clang/unittests/Tooling/CMakeLists.txt

clang_target_link_libraries(ToolingTests
   clangFormat
   clangFrontend
   clangLex
   clangRewrite
   clangSerialization
   clangTooling
   clangToolingCore
   clangToolingInclusions
+  clangToolingInclusionsStdlib
   clangToolingRefactoring
   clangTransformer
   )
 
 target_link_libraries(ToolingTests
   PRIVATE
   LLVMTestingSupport
   clangTesting
 )
 
 add_subdirectory(Syntax)