Introduce truncation into node builder and symbol display part writer

[weswigham]

Fixes #24154

I'd like some feedback/input on some related points:

• Are there any operations which shouldn't allow types to be truncated? (Right now everything other than declaration emit and some refactorings can be)
• How clean does truncation need to be? While the node builder will never build any invalid nodes right now (once it estimates truncation occurs it just starts filling remaining holes with any), the display part writer is less generous and will slice in the middle of a type (though not in the middle of a display part, which is potentially better than error truncation in some ways) - this is maybe fine, but, eg, signature help is actually made up of multiple builder/writer calls, and so has multiple independent truncations occurring (see the example in the test where the constraint is truncated, but then the rest of the signature is printed and an argument type also gets truncated). Should this be fixed? Should signature help bail if it sees a truncation display part added to its part list, rather than continuing?
• Does maximum length before truncation need to be configurable (As an LS setting or compiler option)? Should LS truncation be able to be turned off?
• 2000 is actually a lot of characters. It works out to be around 16 solid lines of text on a wider display like mine - or exactly 25 standard 80 column lines. 25 lines of a single type is a lot of type. Should the default limit actually be even lower (we truncate types in our error messages down to 100 characters)?
• Should whitespace and/or indentation count towards truncation length? As is, it does.

[sandersn]

re your question about multiple truncations: they're really bad. The length is so long that multiple truncations don't appear near each other, and the truncation start looking like some kind of Typescript-specific syntax.

That said, I have no idea how to make things better besides some vague ideas that sound like a lot of work.

[sandersn]

Tracking the max length state at each level of the tree walk is a start, but I think a complete solution would also be able to abort at any level of the tree walk too. Specifically, globally abort and then truncate instead of aborting and truncating locally.

[sandersn]

I don't understand why the code here doesn't do that, actually. Why don't the short-circuits in witeKind et al implement a global truncation?

[weswigham]

They're global within the context of a single writer, however signature help composes multiple writer calls to build the full display...

[sandersn]

Oh no :(

[mhegazy]

that seems a lot.. not sure what is a good number.. but 100 seems slightly too short.. so may be something in the range of 150 - 200..

[weswigham]

240 because that's 3 80 character lines?

[mhegazy]

the approach here is similar to that that we are doing today but giving more room, and avoiding doing the work if we know we are going to through away.. so that OK.. but what i had in mind is to be a bit smarter.. e.g. for a type with too many properties, limit the number of properties, e.g. { a: number, .... z: number } | undefined instead of { a: number, b: number, .... . Similarly, something with multiple levels of nesting, cutting the depth instead of cutting the breadth, so { a: { ... }, b: number, c: string } instead of { a: { nested1: { nested2: { nested3: ...

[weswigham]

e.g. for a type with too many properties,

Ehhh..., the thing is, 20 x: number is really short, but one x: A<B<C<D<E<F<G<H<I<...>>>>> is really long (and there's not really a great way to shorten generic instantiations, AFAIK). A cutoff would be arbitrary and wouldn't have a great correlation with text length.

[weswigham]

Hmmmm I can probably make truncation a bit smarter in a similar way though, at the cost of adhering to the max length less strictly.

[mhegazy]

I do not think we have a hard limit on the number of characters, it is ok if we are a few chars off as long as 1. we have a readable type, and 2. we are not doing a lot of type-2-node work that we will through away

[weswigham]

@mhegazy we now have fancy truncation:

type DeeplyMapped = {
    _0: {
        _0: ["_0", "_0", 0, 0];
        _1: ["_0", "_1", 0, 1];
        _2: ["_0", "_2", 0, 2];
        _3: ["_0", "_3", 0, 3];
        _4: ["_0", "_4", 0, 4];
        _5: ["_0", "_5", 0, 5];
        _6: ["_0", "_6", 0, 6];
        _7: ["_0", "_7", 0, 7];
        ... 491 more ...;
        _499: [...];
    };
    ... 498 more ...;
    _499: {
        ...;
    };
}

There's also a hard limit of 10x the default truncation length (of 160) where it'll just stop and append ... still; just in case any really long structures occur which can't be fancily truncated (ie, a 1000 character identifier).