Type names in a line comment may break the line

[netdpb]

addComment() replaces all the spaces in the format string with · for nonbreaking space, but not spaces in type arguments.

builder.addComment("this is a long line with a possibly long type: %T", someLongParamterizedTypeName);

The above could end up generating code like

// this is a long line with a possibly long type: List<Map<String, Collection<Map<WackyKey,
  OhNoThisDoesNotCompile>>>>

[ZacSweers]

Thanks for the report and repro case. Unfortunately the fix doesn't look too simple, so I would suggest working around this by writing the type to a string first and then adding that as a literal to the comment

val longName = someLongParamterizedTypeName.toString()
builder.addComment("this is a long line with a possibly long type: $longName");

not as pretty, but should workaround this for now

[glureau]

What do we expect here?

// this is a long line with a possibly long type: List<Map<String, Collection<Map<WackyKey, OhNoThisDoesNotCompile>>>>

or

// this is a long line with a possibly long type: List<Map<String, Collection<Map<WackyKey,
//   OhNoThisDoesNotCompile>>>>

First option is a 1~2 char changes I suppose + unit tests, if we choose to never wrap spaces in a long type, I can create the PR if it can help.

Second option looks like #744 in the way line wrapping today doesn't have the context of "in comment block" or "in string" while wrapping. Should we add this concept there (in LineWrapper)? Because it could mean that the comment/big string blocks are known before wrapping, but lost while emitting string, and re-captured from string to process the line wrapping, looks a bit tricky.

EDIT: just discovered #532 and #274 maybe the same discussion?

[netdpb]

I personally think the first option is fine. I think that's what the code does with the non-type string.

[Egorand]

Yep, agree that option 1 is fine. Type declarations aren't usually wrapped in handwritten code, and I think it's fine to ignore the line limit for this case.