disallow recursive references for block-scoped bindings

[vladima]

Fixes #2188

[JsonFreeman]

Did anything change here (can't tell cuz it moved)?

[vladima]

no, code was just moved from emitter to utilities

[vladima]

All TypeScript errors are effectively warnings since they never block emit

[JsonFreeman]

@mihailik, your point is true of type errors as well, but we still report static errors for them. The idea is that we report an error on something if it will be an error when/if you get there.

[JsonFreeman]

👍

[mihailik]

Let-recursivity is statically unknown in a general case, here's a very simple example:

let x = someFunc() > 0.9 ? x : 10;

For type errors the intention behind the code is very clear: type specification is a promise by the code writer. If it statically breaks, it's safe to point out a broken promise.

For let-recursivity cases, it's not as clear what is intentional and what is not. And much worse, there is no syntax to silence the checker (for type checks you can always cast to < any >).

[mihailik]

Judging by the code and tests, the current behaviour is to report an error if x is used in its own initialiser expression, except for when it's used inside a function expression.

That sounds a reasonable balance to limit false positives and false negatives to edge case minority.

Being such a non-trivial error, it would be great to call out this validity check in the TS spec.