Assertion methods (`asserts this is`) are not CFA'd without error

TypeScript Version: 4.0.5, 4.1.0-beta, 4.2.0-dev.20201112

Search Terms:

• Multiple assertion methods
• "asserts this is"
• assertion "cfa"

Code

class X<T, Locked extends boolean> {
    public x: null | T | (Locked extends true ? 1 : 2) = null

    public assert<U>(): asserts this is X<U, Locked> { }
    public lock(): asserts this is X<T, true> {}
}

const x: X<string | number, false> = new X<string | number, false>()

x.assert<string>()
// x is X<string, false> here

x.lock()

Expected behavior:

Either:

• After x.lock(), x is narrowed to X<string, true>
• Or, the x.lock() line throws at compile-time due to not being CFA'd

Actual behavior:

After x.lock(), x is narrowed to X<string, false> & X<string | number, true>.

Playground Link: https://www.typescriptlang.org/play?ts=4.2.0-dev.20201112#code/MYGwhgzhAEAaA8AVANNAMge2AawKYBNpcAPAF1wDt8YAjDDEXMCgPmgG8BYAKGj+gAOAVxogAlsGjEAXNApCQIaAB9oiFdAAUmHASJlK1aKQBOQ3NAD80AIzRZAJgCU0ALxyFIHj36CR4yUgIXBNSeABVFk0nWSCQ0hhSAAsxGFS4CNQdPHw2dmgAXx9+YVEJaBAsbGjYqHjElLSYBBRjM1w8ou4unmAMCghSKVkEQZMxCgBzDXkAWxoQ1AAzMBBgtncKXAB3DLGJ6dU5hZNl1fXo725iADo40Ph9qainHgB6N6lodNHTA7O1h1oEkQrgrvhcKAwCYLEshBRgKQxP0KlUkFEAG4jJCoOgMJisGLQe4JaAY77NHFtcwsK63So4S7cIA

Analysis:

x being typed as X<string, false> & X<string | number, true> shows that the x.lock() narrows from the original type (X<string | number, false>) instead of the narrowed type at that position (X<string, false>).

If instead a "top-level" assertion function is used the type is properly narrowed:

class X<T, Locked extends boolean> {
    public x: null | T | (Locked extends true ? 1 : 2) = null

    public assert<U>(): asserts this is X<U, Locked> { }
    public lock(): asserts this is X<T, true> {}
}

const x: X<string | number, false> = new X<string | number, false>()

x.assert<string>()
// x is X<string, false> here

declare function lock<T>(v: X<T, boolean>): asserts v is X<T, true>
lock(x)

Playground

This leads me to believe this is an issue with the x.lock() call not being CFA'd, in which case the correct behavior would be to throw ts(2775) on the x.lock() line.

首先运行提供的 TypeScript Playground 复现代码，并比较 x.assert<string>() 和 x.lock() 之后的控制流 narrowing。调查编译器对 asserts this is 方法以及所报告的交叉类型的处理方式。当第二个 assertion 要么 narrowing 为 X<string, true>，要么报告预期的编译时错误，并且该示例具有回归覆盖时，即视为完成。