Control flow analysis for implicit any variables

[ahejlsberg]

This PR introduces control flow analysis for let and var variables that have no type annotation and either no initial value or an initial value of null or undefined.

function f(cond: boolean) {
    let x;
    if (cond) {
        x = "hello";
        x;  // string
    }
    else {
        x = 123;
        x;  // number
    }
    return x;  // string | number
}

function g(cond: boolean) {
    let y = null;
    if (cond) {
        y = "hello";
    }
    return y;  // string | null
}

In the example above, x and y implicitly have declared types of any but control flow analysis can determine their actual types at every reference. Therefore, no errors are reported even when the example is compiled with --noImplicitAny.

Control flow analysis is unable to determine the actual types of implicit any variables when they are referenced in nested functions. In such cases, the variables will appear to have type any in the nested functions and errors will be reported for the references if --noImplicitAny is enabled.

function f(cond: boolean) {
    let x;  // Error: Variable 'x' implicitly has type 'any' in some locations where its type cannot be determined.
    if (cond) {
        x = "hello";
    }
    else {
        x = 123;
    }
    return x;  // type string | number
    function bar() {
        const y = x;  // Error: Variable 'x' implicitly has an 'any' type.
    }
}

In time it is possible that control flow analysis will be able to more accurately determine types of references to outer variables from nested functions in some cases, but given that nested functions are first class objects that can be arbitrarily passed around and called, it is effectively impossible to analyze all such scenarios.

[sandersn]

A couple of questions each about the change and the tests, plus a couple of ideas for the tests.

[sandersn]

Can this work for [] or {} as well?

[ahejlsberg]

Yes, but they each need specialized strategies and I'll cover them in separate PRs.

[sandersn]

What does this change and why? I'm guessing that now we can get the type of a symbol given a child of the symbol's declaration, but I can't guess why.

[ahejlsberg]

This is a bug that somehow got introduced during some refactoring for the new emitter. The old isExpression was renamed to isPartOfExpression and a new isExpression was introduced that doesn't look at the context (i.e. doesn't access the parent property).

[sandersn]

why add any here? Is it to preserve the intent of the tests — does control flow pick a union type for these variables now?

[ahejlsberg]

The test just needed some values of type any but they aren't actually meaningful once we start analyzing control flow.

[sandersn]

I thought that auto typing didn't apply to ambient contexts. Why did you have to add any here?

[ahejlsberg]

Yeah, you're right about that. But having them doesn't hurt and is a better indication of intent (i.e. we expressly don't want CFA here).

[sandersn]

I don't understand why auto typing would apply here either

[ahejlsberg]

Same here.

[sandersn]

It would be nice if these functions had names that showed what they were testing.

[sandersn]

if you have if (cond) .. else then y: string | number, right? Might be nice to have a case for that.

[ahejlsberg]

@mhegazy Want to take a look?

[jods4]

@ahejlsberg
Reading the descriptions, I have the impression that the following code example won't be a --noImplicitAny error. Am I wrong?

function f(x: number[]): void { ... }

let x = [];  // x: any[]
x.push(3); // x: number[]
f(x); // x is ok according to control flow, so no --noImplicitAny error?

[mhegazy]

Am I wrong?

You are correct. this is not flagged as an implicit any error.

[jods4]

@mhegazy this is not safe, though.
Consider that f() might use the x value later (through capture or saving into a global variable) and the code might arbitrarily change x.

function f(x: number[]): void {
  setImmediate(function () { 
    console.log(x.reduce((a, b) => a * b, 1));
  });
}

let x = [];
x.push(3);
f(x);
x.push("I am not a number"); // ok, now x: (string|number)[]

[sandersn]

Typescript is already unsafe in this way. You can also write

let sns: (string | number)[];
f(sns);

[sandersn]

Never mind, I was completely wrong. It doesn't work.

[jods4]

@sandersn
Yeah, I like that this enables more errors to be caught when migrating (untyped) JS code.
I like that you now can drop more type declarations for local variables as long as you use them correctly.

But I think many people like TS for being (for the most part) statically type-safe and use noImplicitAny to guarantee that no dynamically typed code slips through, i.e. as a way to enforce type safety.
Currently, this PR weakens the guarantees provided by noImplicitAny and allows some unsafe code that was not possible before.

Thus, I would suggest that you limit what is allowed by this feature or (harder) only allow cases that are provably correct (e.g. determine that the dynamic type never changes to an incompatible type).

I can at least imagine the following operations to be potentially unsafe: saving the value in an object, an array or a variable in an outer scope; assigning the value to a setter; passing the value to a function; capturing the value in a closure; calling a member of the value; new-ing the value.

[mhegazy]

@jods4, the compiler today does not guard against side effects in multiple places. it is not specific to noImplicitAny checks. for instance:

function f(x: { a: number }) {
    setTimeout(() => {
        x.a.toFixed();
    }, 10);
 }

var x: { kind: "number", a: number } | { kind: "string", a: string };

if (x.kind === "number") { 
    f(x);
}

x.a = "string"; // potentially unsafe, as x has already been captured.

Arrays are just like objects with properties when it comes to narrowing. I do understand your concern, but really this issue is a general design limitation and not specific to this change.

[jods4]

@mhegazy
Yes, I agree.
That's why I said TS is for the most part statically type-safe, which is already a lot 😃

That said, having safety holes doesn't necessarily mean we should add new ones. I guess the question is: do benefits outweight the drawbacks?

Your example is a lot more convoluted than the simple example I gave, which was just:

let x = [];
x.push(3);
f(x);
x.push("NaN");

I guess what annoys me most here is that this is unsafe because I use x in a dynamic way, without declaring my intent, under noImplicitAny. I think the essence of noImplicitAny is to forbid errors from unwanted dynamic code.

My opinion:

1. This is great for migrating existing JS code and I wouldn't change anything in this context.
2. I believe people who use noImplicitAny have little use for that feature. Typically those people want maximum safety and try to have everything typed. In this context and with all the inference we already have, you seldom have the need for this shortcut. In my company we build web apps exclusively in this model and I can't say I ever had feature envy for that.

To maximize both safety and value, I would suggest that under noImplicitAny, the dynamic type of locals cannot be changed. I.e.:

let x;  // this is not an error yet.
x = 4;  // so x: number at this point
console.log(x.toFixed());  // sure
x += 5;  // and so on...

let y;  // same thing
y = 4;  // so y: number
y = "Four";  // still an error when --noImplicitAny. Can't use dynamic types without explicit declaration.