================
@@ -92,11 +96,39 @@ class DataflowAnalysisContext {
/*Logger=*/nullptr});
~DataflowAnalysisContext();
+ /// Sets a callback that returns the names and types of the synthetic fields
+ /// to add to a `RecordStorageLocation` of a given type.
+ /// Typically, this is called from the constructor of a `DataflowAnalysis`
+ ///
+ /// To maintain the invariant that all `RecordStorageLocation`s of a given
+ /// type have the same fields:
+ /// * The callback must always return the same result for a given type
+ /// * `setSyntheticFieldCallback()` must be called before any
+ // `RecordStorageLocation`s are created.
----------------
martinboehme wrote:
> I was wondering if having a single `SyntheticFieldCallback` will be too
> restrictive in the future. What if an ananlysis wants to use modeling both
> for optionals and some other data structure, both having its own callbacks?
A single synthetic field callback can handle any number of different types, so
the analysis wouldn't need to set more than one callback.
Maybe, however, you're thinking of a scenario where we might want to run
several analyses at the same time? I think this is something we've discussed in
the past, and in this scenario each analysis would of course potentially want
to be able to set its own synthetic field callback. As we currently don't have
the ability to run more than one analysis at the same time, I think it is
currently sufficient to only support a single callback as well.
https://github.com/llvm/llvm-project/pull/73860
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
