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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
