Show more of the overlong type on type-length error

[kornelski]

The long type-length error trims the type too much, and makes it very hard to identify where the offending type comes from (like in #76785).

Longer type length won't be pretty in terminals, but may help diagnosing the problem.

[rust-highfive]

r? @ecstatic-morse

(rust_highfive has picked a reviewer for you, use r? to override)

[ecstatic-morse]

I don't run into these errors often, but I would rather have the short version of the error for both of the cases in the test suite. Brevity can also be helpful for debugging. Presumably 256 was chosen because it gives good results for the case in #76785? It seems that the problem there is more about where the break occurs. What about tracking delimiters (<, (, { and [) until the character threshold is reached?

@eddyb wants to remove this class of errors entirely. Maybe they have a stronger opinion than I do?

[kornelski]

Test files are autogenerated by the "bless" command, so I don't think I can trim them.

I know it looks messy, but it is an inherently messy error. If it doesn't show the long ugly type, then it's not known what the ugly type is about.

I can't think of a simple heuristic to display only "interesting" part of a type. It's not as easy as skipping punctuation, since opaque types are also noise and have non-trivial syntax. Trying to pretty-print a 350MB-long type would be difficult, and might end up with something silly like a million spaces of indentation.

[kornelski]

Oh, I have an idea! rustc could write the full multi-megabyte type name to a temp file on disk, and the error message can print the file name.

Implemented in #76843