================ @@ -0,0 +1,181 @@ +//===- TUSummaryExtractorFrontendAction.cpp -------------------------------===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// + +#include "clang/Analysis/Scalable/Frontend/TUSummaryExtractorFrontendAction.h" +#include "clang/AST/ASTConsumer.h" +#include "clang/Analysis/Scalable/Serialization/SerializationFormatRegistry.h" +#include "clang/Analysis/Scalable/TUSummary/ExtractorRegistry.h" +#include "clang/Analysis/Scalable/TUSummary/TUSummary.h" +#include "clang/Analysis/Scalable/TUSummary/TUSummaryBuilder.h" +#include "clang/Analysis/Scalable/TUSummary/TUSummaryExtractor.h" +#include "clang/Basic/DiagnosticFrontend.h" +#include "clang/Frontend/MultiplexConsumer.h" ---------------- boomanaiden154 wrote:
> So my question is this: did bazel complain about circular dependencies? For this PR, yes. We can work around it and split the libraries so that it doesn't if this is the preferred approach though. > What would you or anyone on this thread recommend to structure the code? (I > tried my best, but if there is room for improvement, I'm happy to adapt it) I'm not familiar enough with clang/this code to be able to make a recommendation. But generally I think we should having folders under `<project>/lib` depend on each other in a circular fashion, even if they are sufficiently partitioned such that the dependency is not circular. https://github.com/llvm/llvm-project/pull/185656 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
