Display narrowed type of properties in `completionEntryDetails`

[DanielRosenwasser]

interface Palette {
    red?: Color;
    green?: Color;
    blue?: Color;
}

type Color = string | [number, number, number];

function checkOrange(p: Palette) {
    if (typeof p === "object" && "orange" in p && typeof p.orange === "number") {
        p./**/
    }
}

Request completions at /**/ and select the option for orange.

Today, we show

(property) orange: unknown

[
    {
        "name": "orange",
        "kindModifiers": "",
        "kind": "property",
        "displayParts": [
            {
                "text": "(",
                "kind": "punctuation"
            },
            {
                "text": "property",
                "kind": "text"
            },
            {
                "text": ")",
                "kind": "punctuation"
            },
            {
                "text": " ",
                "kind": "space"
            },
            {
                "text": "orange",
                "kind": "propertyName"
            },
            {
                "text": ":",
                "kind": "punctuation"
            },
            {
                "text": " ",
                "kind": "space"
            },
            {
                "text": "unknown",
                "kind": "keyword"
            }
        ],
        "documentation": [],
        "tags": []
    }
]

This has to do with how we decide to display properties - we simply request the type of what p is narrowed to, not the type of individual properties. This is actually part of another weirder distinction, where narrowing a property doesn't also narrow the containing value's type.

Recently there's been some discussion around whether we could do that; however, I am a bit skeptical here. Short of that, it would be nice to show users the actual type they're using.

This could get a little bit expensive; but narrowing in general should get cheaper. In theory, #51525 could avoid much of the work, and make the overhead here very low.

[fatcerberus]

I was under the understanding that, in the general case, narrowing the parent object of a property-based type guard was too complex/expensive/complicates things by creating unwieldy intersections, and that’s why we have discriminated unions. There’s also the issue of what to do with a type guard applied to a.b.c.d - does the narrowing propagate recursively, because that feels like it could quickly get out of hand in terms of complexity.

[DanielRosenwasser]

Right - that's a thing that would fix this, but I'm specifically not saying we should come up with a new general narrowing scheme. I'm only suggesting that for things like calculating display for completionEntryDetails, we should get the narrowed type of that symbol.

But maybe that's already weird for things like quick info on the containing object being out of sync.

[JulioC]

I have a simpler case where this also happens:

const obj: {prop?: string | undefined} = {} as any

console.log(obj.prop)
//             ^?

if (obj.prop) {
  console.log(obj.prop)
  //             ^?
}

https://www.typescriptlang.org/play?noUnusedLocals=true&noUnusedParameters=true&checkJs=true&allowJs=true&module=1&emitDeclarationOnly=true&stripInternal=true&ts=5.1.6#code/MYewdgzgLgBCBGArAXDA3gBwE4gwflWiwEswBzGAHxgFcwATAUwDNTH6YBfGAXnW4CGEGALABPANwAoKaEggANowB0CkGQAUCRMuy4AlNID0RmGfMXzAPTwzizGFqS6cGfeilm5ERSrWbtFwNpMxNLcLMbKU4pIA