Support type variables in MaD typings

[asgerf]

This adds some features related to generics, to support generating MaD typings from .d.ts files and similar.

Type variables

To track types through generics, we encode all the paths leading from some type to all uses of its type variables.
For example for this type,

interface Node<T> {
  value: T | undefined;
  resolve(): Promise<T>;
  next: Node<T>;
}

we'd generate the following rows in a table "type variable" table of form name;path:

Node.T;Member[value]
Node.T;Member[resolve].ReturnValue.Awaited
Node.T;Member[next].TypeVar[Node.T]

Suppose we want to record how to obtain an instance of ImportantObject from mylib, given this declaration

export function create(): Node<ImportantObject[]>;

we'd generate this type-definition row:

mylib;ImportantObject;mylib;;Member[init].ReturnValue.TypeVar[Node.T].ArrayElement

The rule is that the access path token TypeVar[name] can be expanded to any of the paths given by a name;path row with a matching name. Type variables are really just non-terminals in a context-free grammar, but since they have a 1:1 relationship with type variables, I decided to name them after this use-case.

Type-variable rows are thus similar to type-definitions in that the offer a way to reuse access paths, except they can occur anywhere in an access path, whereas type definitions can only occur at the beginning. Also, type-definitions are associated with a set of API nodes, whereas type variables are just intermediate steps and not themselves associated with API nodes (you can ask for all uses of a given type, but not for all uses of a given type variable).

Whythis types are no longer type variables

this types were previously encoded as an extra type variable, but this caused a lot of TypeVar tokens to occur and became really hard to understand. To demonstrate, suppose Node<T> from above had a method returning this:

interface Node<T> {
  ...
  foo(): this;
}

This meant TypeVar[Node.T] must be expanded to take into account that any number of foo() calls may occur initially:

Node.this;
Node.this;TypeVar[Node.this].Method[foo].ReturnValue
Node.T;TypeVar[Node.this].Member[value]
Node.T;TypeVar[Node.this].Member[resolve].ReturnValue.Awaited
Node.T;TypeVar[Node.this].Member[next].TypeVar[Node.T]

In practice these this types show up in a lot of places, like every time a type extending EventEmitter was used.

Type steps

Instead of the above, a this type gives rise to a "type step", which is a kind of step between API nodes, which we use for propagating type information. It could also be used as a value-preserving flow step, but for now we just propagate type information.

The Foo type above would give rise to this summary row:

mylib;Foo;;Member[foo].ReturnValue;type

meaning that whenever we see a call to x.foo() where the x might have type Foo, we add a type step from x to x.foo().

[erik-krogh]

I had a really hard figuring out how each of the predicates work, but I think it makes sense now.
(I did a whole lot of quick-evals using your test-case).

But there's one part that turned out empty in the quick-eval, and that part I still don't get.

[erik-krogh]

I don't really get these, and they also don't seem to be used in your tests?

A comment in getNodeFromPath() says that typeStep() is a receiver step, but I don't see where that comes from?

[asgerf]

Right, there really should have been tests for this. Added some tests, which also revealed a bug in getNodeFromSubPath which I fixed.

A comment in getNodeFromPath() says that typeStep() is a receiver step, but I don't see where that comes from?

I renamed it from "receiver step" to "type step" and I missed that comment.

[asgerf]

I had to rebase to fix a conflict, but could you take a look at the commits called:

• JS: add partially failing test
• Also apply type step in getNodeFromSubPath
• Fix typo: receiver step -> type step