someTypeRelatedToType now passes isIntersectionConstituent

[sandersn]

The quick check for intersection sources doesn't pass isIntersectionConstituent, which incorrectly causes excess property checking to happen on intersection constituents.

In this example, the quick check happens when checking g(CC), and incorrectly finds that CP is not assignable to { children?: boolean } even though the latter is part of CP & { children?: boolean }. The result is then cached, which breaks the assignability check on the next line: <CC {...(null as CP) }/>.

This is a 3.6 regression, but the example is so complex that I'm not sure how hard it is to reproduce.

interface F<P> {
    (props: P & { children?: boolean }): void;
    propTypes: { [K in keyof P]: null extends P ? K : K };
}
declare function g(C: F<unknown>): string;
export function wu<CP extends { o: object }>(CC: F<CP>) {
    class WU {
        m() {
            g(CC)
            return <CC {...(null as unknown as CP)} />;
        }
    }
}

Fixes #33133

Edit: Added commentary from the issue:

The basic problem is that the flag isIntersectionConstituent, which is used to exempt intersection constituents from common-property checks ("weak types"), isn't threaded through one particular intersection call in assignability checking. I missed it when threading that flag through more calls in 3.6 (#32582), and my new assertion in overload error reporting caught the mistake. It's quite likely that this assert would have fired a lot more before #32582.

[weswigham]

Suggested change

	const allDiagnostics: Array<ReadonlyArray<DiagnosticRelatedInformation>> = [];
	const allDiagnostics: (readonly DiagnosticRelatedInformation[])[] = [];

to fix that lint failure.

[sandersn]

Our parsing for readonly T[][] is so bad, and yet we have a lint rule requiring it.

[sandersn]

@typescript-bot cherry-pick this to release-3.6

[typescript-bot]

Hey @sandersn, I've opened #33245 for you.