Investigate randomly failing non-null checks

[dcodeIO]

While working on #1129 I noticed that flows and/or assignments do sometimes not correctly pick up non-null state after assigning to a local from a function call in a conditional branch:

      if (tn.skip(Token.COLON)) {
        type = this.parseType(tn);
        if (!type) return null;
      } else {
        type = Node.createOmittedType(tn.range(tn.pos)); // returns non-null
        type = type!; // FIXME: WHY?
      }
      // otherwise type is considered nullable here leading to follow-up errors
     someFuncWantingNonNullable(type); // cannot assign Type | null to Type

There are 8 code locations in the compiler currently with that FIXME: WHY? comment that all look similar, but I didn't yet manage to reproduce this in a smaller code sample. If someone else manages to, that would be super helpful :)

[jtenner]

class Ref {
}

let result: Ref | null = null;

function test(input: bool): void {
  if (input) {
    return;
  } else {
    result = new Ref();
  }
  func(result);
}

function func(input: Ref): void {
  trace("something", 1, <f64>changetype<usize>(input));
}

test(false);

Not exactly minimal, and it probably could be better, but this seems to get the compiler error.

[dcodeIO]

This one seems different, being caused by result being a global, which flows don't yet null-check.

[jtenner]

Got it!

class Ref {
}

function useRef(aRef: Ref): void {}

function otherExample(condition: bool): void {
  let something: Ref | null;
    if (condition) {
      return;
    } else {
      something = new Ref();
    }
    useRef(something);
}
otherExample(true);

  ERROR TS2322: Type 'test-example/Ref | null' is not assignable to type 'test-example/Ref'.

       useRef(something);
              ~~~~~~~~~
   in test-example.ts(25,11)

[dcodeIO]

This one is interesting, but unlike the cases in the compiler can't be solved with a something = something! right after the assignment. Strange, might be another bug.