Circular mapped property is treated as missing when selecting contextual type from intersections #64534

🔎 Search Terms

circular mapped property contextual type intersection index signature reverse mapped type isCircularMappedProperty

🕗 Version & Regression Information

• This changed in commit or PR Fixed an issue with contextual type for intersection properties (take 2) #52095

⏯ Playground Link

No response

💻 Code

type Func<T> = () => T;
type Mapped<T> = { [K in keyof T]: Func<T[K]> };

type Indexed = {
    [key: string]: () => 0 | 1;
};

declare function reproduce(options: number): void;
declare function reproduce<T>(options: Mapped<T> & Indexed): T;

export const result = reproduce({
    name: () => 0
});

🙁 Actual behavior

The call is accepted.

The inferred declaration is:

export declare const result: {
    name: 0;
};

During contextual typing, lookup of the name property through the reverse-mapped Mapped<T> constituent reaches the circular mapped-property guard, so getTypeOfConcretePropertyOfContextualType does not produce a contextual property type from that constituent.

The intersection-specific contextual typing logic introduced in #52095 can then consider applicable index information from other constituents. In this example, the index signature from Indexed provides () => 0 | 1 as the contextual type of name.

That contextual type preserves the returned 0 as a literal type, which allows reverse inference to infer:

T = {
    name: 0;
}

and the call succeeds.

Before #52095, the same code reports TS2769 because no index-signature contextual type is supplied in this situation. As a result, () => 0 is inferred as () => number, which is not assignable to () => 0 | 1.

There appear to be two potentially separate questions here:

1. Whether this reverse-mapped name property should reach the circular mapped-property guard at all.
2. If the circularity guard does apply, whether the resulting lack of a concrete contextual property type should allow the intersection logic to fall back to an index signature in the same way as when no concrete property exists.

🙂 Expected behavior

I am not certain that the pre-#52095 TS2769 result is necessarily the desired behavior for this particular reproduction, since the currently inferred result is sound.

What seems unclear is whether the interaction between circular mapped-property handling and the index-info fallback introduced in #52095 is intentional.

In particular, these situations currently become indistinguishable to the subsequent intersection contextual-typing logic:

1. no concrete contextual property type is found because the property is absent
2. no concrete contextual property type is produced because property resolution was suppressed by the circular mapped-property guard

If those cases are intentionally meant to permit the same index-info fallback, then the current behavior is expected.

Otherwise, either:

• the reverse-mapped property may be reaching the circularity guard when it should not, or
• the reason that concrete property lookup produced no type may need to be preserved so that the intersection logic can distinguish circularity suppression from actual property absence.

The main question is therefore whether this interaction is intentional.

Additional information about the issue

I found this while investigating my PR #64502, which deals with a different circular contextual-typing issue involving static properties.

While tracing contextual property lookup and circularity handling, I noticed that this reproduction reaches a path where lookup of the reverse-mapped property is suppressed by the circular mapped-property check, after which the intersection logic introduced by #52095 uses an applicable index signature as the contextual type.

I narrowed the observable behavior change down to #52095.

Tested revisions:

• 6894ff7f38211589f0f41f8383727c57144857e1 (parent of Fixed an issue with contextual type for intersection properties (take 2) #52095):
  reports TS2769
• e6edc567a3946d203436265c5b525817fe2f708d (Fixed an issue with contextual type for intersection properties (take 2) #52095):
  no error

#38653 introduced the behavior where contextual typing does not attempt to resolve a mapped property when doing so would cause circular type resolution.

#52095 later refactored contextual property lookup for intersections. When getTypeOfConcretePropertyOfContextualType does not produce a type for a constituent, the intersection logic may consider applicable index information unless a concrete property type is found elsewhere.

I instrumented the current checker locally and confirmed that this reproduction reaches the path where contextual typing through the reverse-mapped property is suppressed by the circularity check and the index signature from the other intersection constituent is subsequently used as the contextual type.

I also tested the current checker with that index-signature fallback temporarily suppressed for this case. With the fallback suppressed, the reproduction reports TS2769, matching the behavior from immediately before #52095.

At this point, I don't know whether the defect is specifically in the index-info fallback.

It may instead be that this reverse-mapped property should not be classified as circular at this stage.

The interesting interaction is that a lookup suppressed by the circularity guard and a lookup where no concrete property is available can both result in no concrete contextual property type being returned, while the subsequent intersection logic does not appear to distinguish why that happened.