Forgotten 'await' error doesn't account for strictPropertyInitialization

[DanielRosenwasser]

We recently ran into some breaks in #43004 (comment) as a result of #25330; however, I think this might be a bigger change than we anticipate.

For one, we don't check whether the value is used after checking the value. For another, we don't really think about class properties, which aren't reliable unless using strictPropertyInitialization.

// @strictNullChecks: true
// @strictPropertyInitialization: false

class C {
  yadda: Promise<number>;

  async doStuff() {
    this.yadda = Promise.resolve(42);
  }
}

async function f() {
  let obj = new C();
  if (obj.yadda) {
    await obj.yadda;
  }

  let x = new C().yadda;
  if (x) {
    await x;
  }
}

Finally, there's some sort of bug where this is plainly giving false positives.

let x: Promise<string>;

setTimeout(() => {
  x = Promise.resolve("");
})

setTimeout(() => {
  // this should NOT be an error
  if (x) {
    x;
  }
})

I guess the question is: should these be errors?

[DanielRosenwasser]

Conclusion:

• Checking the body of the if is unnecessary, don't change behavior on that.
• This check can only be done if strictPropertyInitialization is true.
• This check reports false-positives when a closure-captured variable of a Promise is assigned in some functions, and checked for truthiness in another, and that's a bug.

[andrewbranch]

The design meeting notes say

Uncalled functions and unawaited promises should never be an error when the same identifier is referenced in the truthy block

which seems to conflict with

Checking the body of the if is unnecessary, don't change behavior on that

Unless I’m misunderstanding something?

[DanielRosenwasser]

Yeah, seems confusing - I think that might've been a rushed conclusion that overlooked the existing discussion.

[andrewbranch]

Closing in favor of #43514 since we decided on a different fix (#43593)