================
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+// allocated. This is usually stable across runs leading to the stability of
+// ConstraintMap and other containers using SymbolRef as keys.
+template <>
+struct ::llvm::ImutContainerInfo<clang::ento::SymbolRef>
+ : public ImutProfileInfo<clang::ento::SymbolRef> {
+ using value_type =
+ typename ImutProfileInfo<clang::ento::SymbolRef>::value_type;
+ using value_type_ref =
+ typename ImutProfileInfo<clang::ento::SymbolRef>::value_type_ref;
+ using key_type = value_type;
+ using key_type_ref = value_type_ref;
+ using data_type = bool;
+ using data_type_ref = bool;
----------------
steakhal wrote:
I rarely ever de fined my own ImutInfo but I wonder where the data type comes
from. I could only see a single type parameter for this template
specialization, and I was expecting a partial specialization leaving the Data
type unbound. Could you explain this to me?
Maybe we could leave a comment at the `isDataEqual` where the same question
would come up.
https://github.com/llvm/llvm-project/pull/121551
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
