================
@@ -11,17 +11,18 @@
 
//===----------------------------------------------------------------------===//
 
 #include "llvm/Transforms/Utils/ModuleUtils.h"
-#include "llvm/Analysis/VectorUtils.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/Analysis/VectorUtils.h"
 #include "llvm/IR/DerivedTypes.h"
 #include "llvm/IR/Function.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Support/Casting.h"
+#include "llvm/Support/Hash.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/raw_ostream.h"
-#include "llvm/Support/xxhash.h"
+#include "llvm/Transforms/Instrumentation/KCFI.h"
----------------
rupprecht wrote:

Not a build config per se, but I was fixing the bazel build and needed to add a 
dep from TransformUtils -> Instrumentation, and bazel error'd out due to the 
cycle.

Bazel itself is in the peripheral tier, so don't worry about keeping it green. 
But library layering issues are something that should be avoided 
(https://llvm.org/docs/CodingStandards.html#library-layering), and the bazel 
configs are much more sensitive to layering issues than cmake configs are. This 
is one of the few cases where a bazel-specific failure can point to a real 
issue even if bazel failures are categorically not blocking.

https://github.com/llvm/llvm-project/pull/167254
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to