[RFC] avoid printing type suffix with %E

When formatting an integer constant using the %E directive GCC
includes a suffix that indicates its type.  This can perhaps be
useful in some situations but in my experience it's distracting
and gets in the way when writing tests.

Here's an example:

   $ cat b.c && gcc b.c
   constexpr __SIZE_TYPE__ x = 2;

   enum E: bool { e = x };
   b.c:3:20: error: enumerator value 2ul is outside the range of 
underlying type ‘bool’
    enum E: bool { e = x };
                       ^

Notice the "2ul" in the error message.

As far as I can tell, Clang avoids printing the suffix and I think
it would be nice if the GCC pretty printer made it possible to avoid
it as well.

The attached patch implements one such approach by having the pretty
printer recognize the space format flag to suppress the type suffix,
so "%E" still prints the suffix but "% E" does not.  I did this to
preserve the existing output but I think it would be nicer to avoid
printing the suffix with %E and treat (for instance) the pound sign
as a request to add the suffix.  I have tested the attached patch
but not the alternative.

Does anyone have any comments/suggestions for which of the two
approaches would be preferable (or what I may have missed here)?
I CC David as the diagnostic maintainer.

Thanks
Martin

On Wed, 26 Oct 2016, Martin Sebor wrote:

> The attached patch implements one such approach by having the pretty
> printer recognize the space format flag to suppress the type suffix,
> so "%E" still prints the suffix but "% E" does not.  I did this to
> preserve the existing output but I think it would be nicer to avoid
> printing the suffix with %E and treat (for instance) the pound sign
> as a request to add the suffix.  I have tested the attached patch
> but not the alternative.

I think printing the suffixes is a relic of %E being used to print full 
expressions.

It's established by now that printing expressions reconstructed from trees 
is a bad idea; we can get better results by having precise location ranges 
and underlining the relevant part of the source.  So if we could make sure 
nowhere is trying the use %E (or %qE, etc.) with expressions that might 
not be constants, where the type might be relevant, then we'd have 
confidence that stopping printing the suffix is safe.  But given the low 
quality of the reconstructed expressions, it's probably safe anyway.

(Most %qE uses are for identifiers not expressions.  If we give 
identifiers a different static type from "tree" - and certainly there 
isn't much reason for them to have the same type as expressions - then 
we'll need to change the format for either identifiers or expressions.)

On 10/26/2016 10:37 AM, Martin Sebor wrote:
> When formatting an integer constant using the %E directive GCC
> includes a suffix that indicates its type.  This can perhaps be
> useful in some situations but in my experience it's distracting
> and gets in the way when writing tests.
>
> Here's an example:
>
>   $ cat b.c && gcc b.c
>   constexpr __SIZE_TYPE__ x = 2;
>
>   enum E: bool { e = x };
>   b.c:3:20: error: enumerator value 2ul is outside the range of
> underlying type ‘bool’
>    enum E: bool { e = x };
>                       ^
>
> Notice the "2ul" in the error message.
>
> As far as I can tell, Clang avoids printing the suffix and I think
> it would be nice if the GCC pretty printer made it possible to avoid
> it as well.
>
> The attached patch implements one such approach by having the pretty
> printer recognize the space format flag to suppress the type suffix,
> so "%E" still prints the suffix but "% E" does not.  I did this to
> preserve the existing output but I think it would be nicer to avoid
> printing the suffix with %E and treat (for instance) the pound sign
> as a request to add the suffix.  I have tested the attached patch
> but not the alternative.
>
> Does anyone have any comments/suggestions for which of the two
> approaches would be preferable (or what I may have missed here)?
> I CC David as the diagnostic maintainer.
I'm having a hard time seeing how this is a significant issue, even when 
writing tests.

It also seems to me that relaying the type of the constant as a suffix 
would help in cases that aren't so obvious.

What am I missing?

Jeff

On 11/16/2016 11:34 AM, Jeff Law wrote:
> On 10/26/2016 10:37 AM, Martin Sebor wrote:
>> When formatting an integer constant using the %E directive GCC
>> includes a suffix that indicates its type.  This can perhaps be
>> useful in some situations but in my experience it's distracting
>> and gets in the way when writing tests.
>>
>> Here's an example:
>>
>>   $ cat b.c && gcc b.c
>>   constexpr __SIZE_TYPE__ x = 2;
>>
>>   enum E: bool { e = x };
>>   b.c:3:20: error: enumerator value 2ul is outside the range of
>> underlying type ‘bool’
>>    enum E: bool { e = x };
>>                       ^
>>
>> Notice the "2ul" in the error message.
>>
>> As far as I can tell, Clang avoids printing the suffix and I think
>> it would be nice if the GCC pretty printer made it possible to avoid
>> it as well.
>>
>> The attached patch implements one such approach by having the pretty
>> printer recognize the space format flag to suppress the type suffix,
>> so "%E" still prints the suffix but "% E" does not.  I did this to
>> preserve the existing output but I think it would be nicer to avoid
>> printing the suffix with %E and treat (for instance) the pound sign
>> as a request to add the suffix.  I have tested the attached patch
>> but not the alternative.
>>
>> Does anyone have any comments/suggestions for which of the two
>> approaches would be preferable (or what I may have missed here)?
>> I CC David as the diagnostic maintainer.
> I'm having a hard time seeing how this is a significant issue, even when
> writing tests.
>
> It also seems to me that relaying the type of the constant as a suffix
> would help in cases that aren't so obvious.
>
> What am I missing?

I don't think it's terribly important, more like nuisance.  Tests
that check the value printed by the %E directive (I've been writing
lots of those lately -- see for example (*)) have to consistently
use this pattern:

     \[0-9\]+\[lu\]*

When the type of the %E argument is a type like size_t or similar
that can be an alias for unsigned long or unsigned int, it's easy
to make a mistake and hardcode either

     \[0-9\]+lu

or

     \[0-9\]+u

based on the target where the test is being developed and end
up with failures on targets where the actual type is the other.
Copying test cases exercising one type to those exercising the
other (say from int to long) is also more tedious than it would
be without the suffix.

Beyond tests, I have never found the suffix helpful in warnings
or errors, but I also haven't seen too many of them in released
versions of GCC.  With the work I've been doing on buffer
overflow where size expressions are routinely included in
the diagnostics, there are lots more of them.  In some (e.g.,
in all the -Wformat-length) I've taken care to avoid printing
the suffix by converting tree nodes to HOST_WIDE_INT.  But that's
cumbersome and error-prone, and leads to inconsistent output from
GCC for different diagnostics that don't do the same.

Martin

[*] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01672.html