This PR adds tracking of the "rationale" for an escaped value. Currently, this is just the ultimate reason why something is leaked, which can be a go call, a global variable, or an unsummarized function. These rationales need to be propagated by the escape-graph manipulation code, but most of the escape analysis does not need to worry about them.
The test framework for locality tests is updated to allow requiring the rationale to contain a specific string, which is how we ensure the correct rationale is propagated appropriately.
An extension to this would involve tracking the entire trace for why something is leaked, e.g. if it is leaked in some transitive callee, the rationale would include the path through the call-graph that leads from where a leaked value is reported to the go call or global where it is leaked. This would be significantly more friendly to developers using the tool, but isn't necessary for basic experiments.
This PR adds tracking of the "rationale" for an escaped value. Currently, this is just the ultimate reason why something is leaked, which can be a go call, a global variable, or an unsummarized function. These rationales need to be propagated by the escape-graph manipulation code, but most of the escape analysis does not need to worry about them.
The test framework for locality tests is updated to allow requiring the rationale to contain a specific string, which is how we ensure the correct rationale is propagated appropriately.
An extension to this would involve tracking the entire trace for why something is leaked, e.g. if it is leaked in some transitive callee, the rationale would include the path through the call-graph that leads from where a leaked value is reported to the go call or global where it is leaked. This would be significantly more friendly to developers using the tool, but isn't necessary for basic experiments.