Error: Debug Failure. False expression: parameter should have errors when reporting errors

[amcasey]

TypeScript Version: 3dd7b84

Code

interface I1 {
    prop1: string;
}

interface I2 {
    prop2: string;
}

interface I3 extends Record<string, string> {
    prop3: string;
}

type Properties =
    | { [key: string]: never }
    | I1
    | I2
    | I3
    ;


declare const prop1: string;
declare const prop2: string | undefined;

// Error: Debug Failure. False expression: parameter should have errors when reporting errors
function F1(_arg: { props: Properties }) { }
F1({
    props: {
        prop1,
        prop2,
    },
});

// Error: Debug Failure. No error for last overload signature
function F2(_props: Properties) { }
F2({
    prop1,
    prop2,
});

Expected behavior: Compiles successfully in strict mode

Actual behavior: Asserts in strict mode (different asserts for F1 and F2)

Edit: current best guess is that checkRelatedTo should be true and that's why there's no error message. This seems to be related to excess-property checking (related to the fresh object literal at the call site and the index signature in the union).

[RyanCavanaugh]

@jack-williams I thought you might be interested in this if you're looking for a fun bug

[jack-williams]

@RyanCavanaugh Sure thing!

Optimistically pinging @sandersn incase he has any immediate pointers.

Note to self: this was introduced in fb50920

[sandersn]

Not immediate, no. I introduced asserts in that commit to make sure the new changes I made didn't have any bad effects, and in fact the time a different assert failed, the problem was in my new code. (One of my PRs from about a month ago might be relevant.) But this could definitely have been an existing problem. You could introduce that assert into the release-3.6 branch to see whether it repros there.

[jack-williams]

Fix is up at #33828

The root cause is a difference in error checking logic with and without reportErrors on. The object literal is not assignable when reportErrors is false, but assignable when true --- this triggers the assertion errors because the checker is expecting a diagnostic and doesn't get one.

Specifically the issue is that when reportErrors is false, the checker compares the type of property prop2 which is implicitly partial to the raw type undefined, which is false because string | undefined is not assignable to undefiend.

When reportErrors is true the check is made against the optional type of the property, rather than just the raw type undefined --- this consequently passes.

I've made the logic consistent to always compare against the optional type of the property. There is no type error in the example, and now no assertion failure. I think there is an argument to be made about whether an excess property error should be raised here, but I'd rather fix the assertion in a non-breaking way first.