JavaScript: Fix uses of TypeTracker with custom flow steps.

[xiemaisi]

These steps need to check that the type hasn't been tracked into a property.

Before I start testing this, I'd like some feedback on the API. Checking for the property name explicitly is awkward and easy to forget and should probably be encapsulated in an auxiliary predicate, but I'm struggling to come up with an intuitive name and would be grateful for suggestions. Or maybe there is another way to ensure this?

[asger-semmle]

We could add a self-returning predicate like use():

class TypeTracker {
  TypeTracker use() {
    prop = "" and result = this
  }
}

This only happens in cases where we're passing t into the recursive call, and that's where I'd advocate for its use:

exists(string name |
  result = myType(t.use()).getAMethodCall(name)
|
  name = "foo" or name = "bar"
)

[xiemaisi]

I like that idea a lot! A more descriptive name than use would be nice; I'll think about it.

[asger-semmle]

I doubt I'd use it very often, though. I usually just do t.start() and use the "end" version of my predicate to throw away the calling context when a sufficiently specific use is found (as per the firebase.database example from the Firebase PR description).

[xiemaisi]

I usually just do t.start() and use the "end" version of my predicate to throw away the calling context when a sufficiently specific use is found

Yes, I'm sure that is in general the more common pattern. However, when tracking the precise origin of flow (and not just the type), it seems dangerous to throw away calling contexts, so that's why I'm doing it this way.

[xiemaisi]

I've encapsulated the t2.getProp() = "" and t = t2 pattern in a new predicate t = t2.continue().

Evaluation on socket.io-relevant slugs looks fine. The evaluation was before the last commit, but the DIL changes from that commit look harmless; I can do another sanity check if desired.

[asger-semmle]

LGTM