Track inclusion of entities returned by literal methods

[lukastaegert]

This resolves #2253 by internally using instances that can track their own inclusion status for return values of literal methods. E.g. in this example:

const virtual = [1, 2].slice();
virtual.push(3);
const otherVirtual = virtual.slice();
console.log(virtual);

the line virtual.push(3) will be included as virtual itself is included due to the console.log statement. The third line, on the other hand, is still removed as it is no side-effect.

To be able to do that, a larger refactoring was necessary. The main issue was that in order to track the inclusion status of an entity that is not represented by an AST node, another AST node needed to take up that responsibility. In this case, the respective CallExpression seemed the natural choice (each call to Array.prototype.slice creates an independent new object).

Thus I needed to change the fundamental logic that tracks side-effects around return expressions. Instead of e.g. the call expression "asking" a function declaration if calling its return value has a side-effect, the call expression initially asks the function declaration for its return expression, stores this value and then directly performs queries on this return expression.

The only (tested) situation where this performs less optimal than before is when we call an expression that can resolve to more than one possible callable entity. In this case, we just treat the return value as "unknown".

[lukastaegert]

This also provides another noticeable performance boost (e.g. bundling the TypeScript compiler is now >20% faster)

[lukastaegert]

Also note the negative diff :)

[guybedford]

Really great simplification to see.

[guybedford]

Could we return something like THROW_EXPRESSION here if path.length === 0?

[guybedford]

(super obscure edge case I know...)

[lukastaegert]

Sure we could. What is your intention here:

• documentation, or
• improved tree-shaking in certain situations?

I am a little hesitant to do this just in a few places as there are quite a lot of situations where we deoptimize because we would do something illegal and having it done in some places only could leave people falsely relying on this.

If you see some potential tree-shaking benefit, it might be worth doing it in all relevant places in a separate PR.

[guybedford]

Is this not EMPTY_PATH?

[lukastaegert]

Thanks, fixed this in some other places as well.

[guybedford]

I look forward to PossibleExpressionSet :)

[lukastaegert]

Something like this could well be coming with SSA. PossibleExpressionSet is a good name for Phi-functions 😉

[guybedford]

Again could be nice to have THROWS_EXPRESSION or similar.