[PATCH] D134453: Disambiguate type names when printing NTTP types

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D134453#3871251 <https://reviews.llvm.org/D134453#3871251>, @dblaikie wrote:

> @aaron.ballman: thanks for tracking down the source of confusion between our perspectives. (& yeah, sorry, could've included less ambiguous examples with the extra nesting so we'd have avoided all that confusion)

No worries, text is such a fantastic medium for confusion. :-D

> Do you have particular examples where you find the fully explicit (1) especially helpful (to a novice or otherwise) over (2)?
>
> It seems to me once you've got the top level type you have enough info to compare two things, even if you don't know the nested member types - "X<Y{{3}, {5}}>" is distinct from "X<Y{{4}, {5}}>" it doesn't seem to matter what the intermediate type is? but yeah, I guess it raises the question "is it that the length or the height is mismatched here" and more explicit would avoid that question.

That's largely the kind of situation I was imagining. When you just have a pile of integers and braces, you have to mentally map the braces to how many levels of initialization exist and you have to map the integers to what specifically is being initialized. Those mappings gives very little context as to what types are involved. e.g., it's easy to see that `{{3}, {5}}` doesn't match `{{4}, {5}}` in the text, but it's less easy to see if that's because of `Width` vs `Height` problems or because there was a surprise specialization involved, etc.

Sometimes you don't need that extra information and sometimes it may be helpful, and I'm not certain we can heuristically tell those situations apart for the user.

> It does seem unfortunately verbose to my mind - like if we improved the printer to show only the relevant types when diffing template names, for instance, that'd be an improvement (though I guess we already do fancy things for template type diffing that don't show complete copy-paste-into-source usable names anyway, so that's a different situation - and doesn't necessarily say what we should do when the type appears alone in a diagnostic, not as a comparison)

Yeah, it'd be nice to find a happy medium. CC @cjdb due to the exploratory work he's doing with improving the way we display diagnostics. Maybe Chris has a good idea here (or can help us resolve which direction to go)?

> *shrug* Sorry to you both for all the talking/back and forth then. Adding the fully explicit mode will address @dodoent's string-based reflection needs and @aaron.ballman so there's no tension between Clang's diagnostic goals and @DoDoENT's reflection goals.

No worries about the back and forth (at least for me) -- I appreciate that we're taking the time to carefully consider the user experience.

In terms of next steps, I think we should try to see if there's a "clear" path forward in terms of printing the types vs not printing the types. If we find one, then great, we go that way. But if we don't seem to have a clear path forward (relatively quickly; I don't think we want to drag this discussion on for months trying to find the perfect answer), then I think I'm fine with the patch as-is. It fixes the issue of `t<{}>` (with empty braces specifically) while retaining the status quo in other areas, but still exposes useful functionality through the additional printing policy. Does that sound reasonable?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134453/new/

https://reviews.llvm.org/D134453