C#/Java/Go: Neutrals are split into separate classes.

[michaelnebel]

The existing implementation doesn't handle kind and provenance in conjunction with each other as they get mixed in the NeutralCallable class (we basically get the product of the kinds and provenances - see the example below).
The neutral classes are now created based on parameterised modules instead.

If we quick eval the myTest predicate in the following example, we get the tuples (A,A1) and (A,A2).

bindingset[this]
abstract class Base extends string {
  abstract string getValue();
}

class A1 extends Base {
  A1() { this = "A" }

  override string getValue() { result = "A1" }
}

class A2 extends Base {
  A2() { this = "A" }

  override string getValue() { result = "A2" }
}

predicate myTest(A2 a, string value) { a.getValue() = value }``

[michaelnebel]

DCA except for swift looks good.
Will re-run DCA for swift.

[michaelnebel]

After discussing this in the swift channel on slack - it appears that it is not uncommon that DCA shows a slowdown as the execution time is generally low for the swift projects; Accepting the DCA executions for swift as well.

[aschackmull]

Looks reasonable.

[owen-mc]

Now the bug is fixed, isn't this a confusing name? (Same for the java test.)

[michaelnebel]

The method is defined as sink (manual) and summary (df-generated) neutral in the extensible file.
That is, we expect that the "neutral" test (which only reports summary neutrals) would generate a neutral (df-generated) summary for this method.
The name "NoSink" is because it is explicitly stated in the extensible file that this method is sink neutral (it is not a sink).

[owen-mc]

Ah. Thanks for explaining.