In the process of adding more dataflow to C/C++ we've seen a large performance regression on a codebase that contains code like:

void foo(int opcode, A* a) {
  switch(opcode) {
    case 0: /*...*/ break;
    case 1: /*...*/ break;
    ...
    case N: /*...*/ break;
  }
}

where the code inside /* ... */ causes the dataflow library to create a giant number of access paths:

As @aschackmull pointed out, this looks a lot like a virtual dispatch hierarchy like (sorry for my bad Java 😅):

public interface Foo {
  public void foo(A*);
}

public class Foo1 implements Foo {
  public void foo(A* a) { /* ... */ }
}

public class Foo2 implements Foo {
  public void foo(A* a) { /* ... */ }
}

...

public class FooN implements Foo {
  public void foo(A* a) { /* ... */ }
}

and when written like that, the dataflow library recognizes that such calls to foo may have a high fan-in/fan-out.

However, it's not clear how the dataflow library would recognize the switch pattern above to selectively disable field flow for such cases. Thus, this PR adds a new predicate that can be overwritten for each language to increase the join and branch values when calculating the expected fan-in and fan-out.

I've only implemented a "flow-into" version as this was the only thing that was necessary to fix the performance on C/C++.

Implementing this new predicate as none() (as I've done so in this PR) will preserve the current fan-in/fan-out estimates. I hope that makes this PR uncontroversial.

Once we implement the predicate for C/C++ (which I'll do in a follow-up PR) the stats will be the much more manageable: