[PATCH] D135245: [clang][Tooling] Move STL recognizer to its own library

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 6 00:51:28 PDT 2022


kadircet marked 2 inline comments as done.
kadircet added inline comments.


================
Comment at: clang-tools-extra/clangd/CMakeLists.txt:163
   clangToolingInclusions
+  clangToolingInclusionsSTL
   clangToolingSyntax
----------------
sammccall wrote:
> StandardLibrary or Stdlib?
> 
> STL isn't accurate or consistent with the names in the code.
changing to Stdlib


================
Comment at: clang/lib/Tooling/Inclusions/STL/CMakeLists.txt:2
+add_clang_library(clangToolingInclusionsSTL
+  StandardLibrary.cpp
+
----------------
sammccall wrote:
> 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
> 
> 
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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135245/new/

https://reviews.llvm.org/D135245



More information about the cfe-commits mailing list