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

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D134453#3885423 <https://reviews.llvm.org/D134453#3885423>, @aaron.ballman wrote:

> I can live with this approach if folks think it's the better way to go. But my concern still remains that the user has no idea what's being constructed by `{3}` or `{4}` without tracking down which constructor of `t1` is being called. Because of overloads, `std::initializer_list`, and conversion operators (and the fact that C++ initialization rules are a bit of a disaster), I think this can be unobvious sometimes without including type names. That said, after playing around a bit, I think those times might involve more contorted code than others are worried about, and so maybe it's not worth worrying about those cases. The fact that Clang is the only C++ compiler that doesn't print full type information makes me wary though. My thinking is that it's always more frustrating to have not enough information in a diagnostic than too much information (both are problems in their own ways though).

I think the problem here is that since we don't have the as-written argument, we just have the converted argument which is an APValue with the state of the object.
I don't think we can in general, starting from the state, figure out which constructor would produce that state.

So we might print it with a syntax as if the class was a simple pod type, even though that might produce a completely different result if used in practice.
I don't think we can do much better without having the actual expression used.

That might be a point in favor of the designated-initializer style with the field names, that should never produce the wrong result if copy-pasted back to code.

> I can understand it being less readable for deep nesting situations, but I do not see why it would be prone to bad corner cases -- it's the most explicit form we can write (and matches the behavior of all other C++ compilers, from what we can tell).

The types of the fields might be internal, or otherwise too distant from user code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134453