[cfe-dev] __PRETTY_FUNCTION__ output loses enum type info for non-enumerated values

[will wray via cfe-dev]

A request to change Clang's __PRETTY_FUNCTION__ output to fix an issue.

The code used in pretty function is also used to generate debug info in
DWARF etc
.
(I believe). See, for instance the comment on this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=21492#c1

> Clang shows these arguments with the same DW_AT_name, X<1>, but they're
> distinct types


https://godbolt.org/z/0Ik0Hl
Pretty function output, for auto... args
(variadic just so that outputs display together):

template <auto... V>
constexpr char const* auto_name()
{
return __PRETTY_FUNCTION__;
}

enum e { a, b, c=b };
enum class E { a, b, c=b };

char const* nameU() { return auto_name<a, b, c, e(3)>(); }
char const* nameS() { return auto_name<E::a, E::b, E::c, E{3}>(); }


Gives output with these strings embedded;

nameU:
<a, b, b, 3>

nameS:
<E::a, E::b, E::b, 3>


The first two enumerated values, a & b, are returned with no loss of type
info as a, b.
The next enumerated value, c, is a duplicate label for b's value, and is
reported as b.
The final value is not enumerated - there is no enum label with value 3 -
it is reported with an unnecessary loss of type info
as plain digits 3.

The non-enumerated value should be reported with a cast or constructor:

unscoped e: 3 -> (e)3 or e(3)

  scoped   E: 3 -> (E)3 or E(3) or E{3}

 (init-list E{3} only for scoped enum and only since c++17)


Question 1:

Will it be acceptable to change the output for non-enumerated values as so?
This will retain type info and allow round-trip without loss.
Either C-style cast (e)3  or  function-cast / type-constructor e(3) - seem
ok
(gcc uses C-style casts and Clang uses this same style in source labels).

For the duplicate-valued labels case there is no loss of type info,
but there is a loss of information about the label used for the auto arg.
Presumably, the code works from the supplied underlying-type value
and picks the first label with the given value. I'd guess that Clang knows
the label used in a direct instantiation and could return it in that case.
(c.f. named member-pointer args have to retain the id for reporting).

Question 2:

Is it possible / acceptable to retain the label in the duplicate enum value
case?

Can anyone point me to the relevant code?

Thanks, Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180904/3371c119/attachment.html>