Don't error with "used before assigned" when declared type includes void

[Andarist]

fixes #52003

[Andarist]

The problem is that the typeof expression is the antecedent of the value variable here and it changes the void type somewhat unexpectedly.

narrowTypeByLiteralExpression discards void from string | void type for the assumeTrue === false case here.

So when we get to this line here we have:

type // string | void
flowType // string | undefined

As the other antecedent pushes undefined into the antecedentTypes in the getTypeAtFlowBranchLabel.

I don't think this can be changed since this is how TS behaves today:

declare const a: string | void

if (typeof a === 'undefined') {
  a // undefined
}

if (typeof a !== 'undefined') {
  a // string
}

So checking against voidType here was my best shot at fixing this.

EDIT: Alternatively... maybe the antecedents are set incorrectly here. I don't quite understand why value is "linked" to this binary expression. I didn't dive into CFA implementation too much yet so I didn't even attempt to explore the possibilities there

[fatcerberus]

FWIW:
While the “used before assigned” error definitely seems like a bug, I note that it’s never sound to narrow void out of a union, as the whole point of void is that it specifies a “return arity” of zero, and any function type with higher return arity (i.e. any other return type) is assignable to it. So if you do something like cond ? voidRet() : stringRet() and get a string | void, you can’t be sure, even if you get a string back, that it’s not bogus, since voidRet may in fact have returned a string, but its void return type is an implicit promise that the caller won’t access anything it happens to return (since in reality “zero return arity” isn’t a thing).

[Andarist]

@fatcerberus ye, I realize that - but TS is very conservative about breaking changes, and apparently this is the current behavior:

declare const a: string | void

if (typeof a === 'undefined') {
  a // undefined
}

if (typeof a !== 'undefined') {
  a // string
}

That's why I've implemented this as a fix. Personally, I would prepare a different fix - one that wouldn't remove void from the union etc but to do that I would have to get a signal from the TS team member that this is what they want.

[sandersn]

From reading #52003, I think the Not A Defect tag means that we don't want to fix that bug. So I think this PR should be closed?

@RyanCavanaugh feel free to speak up if I interpreted Not A Defect incorrectly.

[fatcerberus]

FWIW Not a Defect tag was added after the PR was opened.

[RyanCavanaugh]

Yeah, this is the kind of fix we need to reject if we don't want to bleed performance forever. People should not be declaring variables of type void in the first place.