GeezerVison

1. Not every Node has an id property (at runtime it is undefined). Is that correct or a bug? I currently use flowIndex (which I will remove later on) in getPreviousOccurencies, but id would be better.

Use the function getNodeId to get node id's - if the node has yet to be assigned one, this function assigns it one.

After a bit of sniffing with your code, I think the (or one of the?) test(s) which hangs is tests/cases/conformance/parser/ecmascript5/parserRealSource7.ts (which I think is a chunk of code form the original compiler). The preCollectFuncDeclTypes function within the file is enough (on its own) to make the test hit the memory ceiling. It seems to spend a lot of cycles re-narrowing the ast cast-and-assignment-to-funcDecl in that function (and in some other places, too).

It took a while, but I think most things are working now. I have updated the PR for the dotted names type guards and this type guards. null and undefined worked without extra work. I haven't used the control flow graph for variable assignment checking, but that can be easily added later on.

I think that two minor problems: handling of a try/catch block and getTypeOfSymbolAtLocation. After a try/catch, narrowing breaks and types of variables are set to their initial types. Better would be to use the type before the try if the variable is not assigned within the try, otherwise the initial type; or to take the union of the type before the try with all types of assignments in the try/catch.

The following code compiles, but gives the wrong type in VSCode, with this custom build. When I hover the last x, it says string | number. I suspect this has something to do with getTypeOfSymbolAtLocation, but I'm not sure what's happening. This seems to fail with double type guards. The tests show this too, in tests/baselines/reference/typeGuardsInIfStatement.types.

let x: string | boolean | number;
if (typeof x === "string") {}
else if (typeof x === "boolean") {}
else x.toExponential;

Since most work has been finished, can someone review my code?

For try...catch and try..finally it's very useful to keep the narrowed type of symbols that do not change type in the block, including those that are assigned, so that the following works:

let x: number | null;
x = 4; // from here x: number
try {
  x = 7;
  throw new Error();
} 
finally {
  x.toString(); // <-- should be ok, it would be annoying if x reverts to number|null
}

For symbols, which change type inside the block I am unsure whether it's worth the effort. The union of all their types across the block would be correct but it can get hard to reason about, for IMHO little benefit. I think reverting to their initial type would be OK for a first release, it can always be improved later if people have motivating examples of code where it would be nice.

this functionality should be handled by #8010.

Big thanks to Ivo Gabe de Wolff (@ivogabe) for sharing this work. it has been the inspiration and guide for the work in #8010. thanks again Ivo Gabe de Wolff (@ivogabe)!