On the use-use-flow feature-branch we were getting spurious flow like:

void local_references(int &source) {
  source = 0;
  sink(source); // clean, but was marked as tainted
}

when the source dataflow node was defined as source.asParameter().hasName("source"). This turns out to be because source.asParameter() defaults to source.asParameter(0), which means that the value of source was marked as the source instead of the value of *source (if we pretend that the source is of a pointer type instead of a reference type).

Ideally, the fix in 5e9e7da should be enough to fix this. However, the first commit is a necessary precondition for this. This first commit fixes two things:

• It removes the ad-hoc dataflow we added between reference addresses and their dereferences. That's pretty simple to remove ✔️.
• The second issue is a subtle bug in adjacentDefRead: Previously, when we were flowing from one def/use to an adjacent use we did the following:

defOrUse.asDefOrUse().hasIndexInBlock(bb1, i1, v)
adjacentDefRead(_, bb1, i1, bb2, i2) and
use.asDefOrUse().(UseImpl).hasIndexInBlock(bb2, i2, v)

which amounts to saying:

1. A def/use of variable v is at position (bb1, i1)
2. There's an adjacent-def/use-use relationship between the locations (bb1, i1) and (bb2, i2)
3. A use of variable v is at position (bb2, i2).

However, note that point 2 doesn't talk about which variable is participating in the adjacent-def/use-use relationship. So in our example above, we'd have a use-use relation between source (note: not *source) in source = 0 and source in sink(source). And since source and *source are located at the same index in the same block we'd get use-use flow between *source in source = 0 and *source in sink(source).

The fix is very simple: instead of ignoring the first column of adjacentDefRead we simply check that the variable in question is actually v.