-
Notifications
You must be signed in to change notification settings - Fork 2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add field Projection/Injection metadata in Lineage graph
Summary: The ongoing work on interprocedural analysis aims at improving dataflow precision by removing spurious Derive edges generated on function calls, based on a better understanding of fields concerned by these calls. It relies on the fact that it is sufficient to follow Derive edges only, not Call-then-Return paths, when looking for data flows -- in other words, the Call and Return edges remain largely unaffected by this work, for various technical and theoretical reasons. Yet this assumption is not true when mixing in flows imported from another analysis such as a dynamic one: some actual flows may exist that will go though Call/Return edges (of the same function) and do not have a corresponding Derive edge. This jeopardises the precision improvement expected from interprocedural work. To alleviate this, we add some shape information into those edges, by annotating them with the fields that are projected from or injected into some node. Injection is generated on Call edges and on edges that have a special Return node as destination, meaning that the source only flows into the corresponding field of the destination. Projection is generated on edges from a formal parameter and on Return edges, meaning that only the corresponding field of the source flows into the destination. It becomes then possible to filter out impossible paths by removing those that involves an edge that inject into some field `f`, then only does some Copying, then projects from another field `f'` -- similar to what can already be done on Call stacks to prevent "returning" from a function that wasn't called in the first place. Note that, until further understanding, Derive edges between injection and projection should "reset" this tracking (as they could themselves involve a projection of some sort), and nested fields are to be understood in a "prefix" sense: injecting into `#foo#bar` then projecting from `#foo` doesn't break the chain either. *Implementation details.* Within the internal analysis, we add two knew new kinds of edges, `Project` and `Inject`, and also add field information on the `Call` and `Return` edges. The former are generated to complete the summary of the "current" procedure (replacing some Copies when formals fields are involved), whereas the latter keep being generated upon calling another procedure. The Json output however retains its old edge kinds, but they may now have an additional `edge_metadata` component. When present, its value will be either `{ "projection" : ["nested"; "field"; "list"] }` or `{ "injection" : ... }`. The current diff will not generate "trivial" projections or injections, that is with an empty field list. The schema doesn't forbid an edge that both projects and injects, but that will not currently happen. If the metadata is trivial, il will not be present at all on the edge entity. Reviewed By: rgrig Differential Revision: D43401524 fbshipit-source-id: 12bd5470920868964c23a9252ebfbd8259e57f55
- Loading branch information
1 parent
699c30d
commit c16e1cc
Showing
1 changed file
with
145 additions
and
34 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters