[Bug c++/59980] New: Diagnostics relating to template-specialisations using enums.

[Bug c++/59980] New: Diagnostics relating to template-specialisations using enums.

[gcc-bugs at hussar dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

            Bug ID: 59980
           Summary: Diagnostics relating to template-specialisations using
                    enums.
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugs at hussar dot demon.co.uk

Created attachment 31978
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31978&action=edit
Example source code producing the diagnostic.

I have a minor difference of opinion with the implementation regarding the
formatting of error messages in g++ (v4.4.7, v4.7.2 & v4.8.1, amongst others).
Examples of the error message:

test.cpp:29: error: 'fn' is not a member of 's1<(e1)1u>'
test.cpp:31: error: 'fn' is not a member of 's2<(e2)1>'

And I'd like a way to make the 's1<(e1)1u>' or 's2<(e2)1>' portion in the
message look like 's1<t2>' or 's2<e2::t4>', which is clearer (to me).

The command line used (on g++ v4.4.7 in this case) was:

g++ -Wall -Wextra -std=c++0x test.cpp

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason from comment #0)
> And I'd like a way to make the 's1<(e1)1u>' or 's2<(e2)1>' portion in the
> message look like 's1<t2>' or 's2<e2::t4>', which is clearer (to me).

I agree it would be nice. The difficulty is that there might not be an
enumerator with that value, or there might be more than one with that value, so
printing the same enumerator as was used in the code would require keeping
track of information that is not part of the type system.

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We could keep what we are doing if there is no such enumerator or more than one
(or for the latter case just pick one).

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[gcc-bugs at hussar dot demon.co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

--- Comment #3 from Jason <gcc-bugs at hussar dot demon.co.uk> ---
C-style enums decay to the underlying integer representation, this particular
behaviour helps complicate considering how any modification to the diagnostic
might be implemented. Enum-classes are not without their own set of
complications, 
but these are fewer than C-style enums, and might be more amenable to
implementing this modification of the diagnostic. As I see it the basic problem
is that the mapping of integers to sets-of-{of enumerator values} is not unique
for C-style enums. The issue is one of choice: (expression) can map to
{enumerator-names}, so which should one choose? But if one were to restrict
oneself to enum-classes, the mapping of (expression) to sets-of-{of enemerator
values} has been broken: one must explicitly cast, so at the cast-site the
particular enumeration is known, and if the results maps to an enumeration
value, it can be printed, otherwise the value could just be printed, with the
cast, as is done already. In particular, in my example of the
template-specialisation, the target enum-class is known, therefore the
diagnostic can reasonably coerce the result of the expression to a matching
enumeration-value, if it exists, and print that name. Of course one would need
to ensure that the enumerator-names have been stored with the enumerator-values
within the enumeration to allow this to occur.

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason from comment #3)
> C-style enums decay to the underlying integer representation, this
> particular behaviour helps complicate considering how any modification to
> the diagnostic might be implemented.

I don't see how the decay is relevant, if the template parameter is of type E
then the compiler's IR stores a value with that type, not an integer, so
there's no decaying.  For the purposes of this diagnostic I don't see any
difference between scoped and unscoped enums.

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[gcc-bugs at hussar dot me.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

--- Comment #6 from Jason <gcc-bugs at hussar dot me.uk> ---
And lo! Finally! This appears to have been done in g++ v9.3.0. Amazing! Huzzah!

[Bug c++/59980] Diagnostics relating to template-specialisations using enums.

[gcc-bugs at hussar dot me.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980

Jason <gcc-bugs at hussar dot me.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |9.3.0
         Resolution|---                         |FIXED

--- Comment #7 from Jason <gcc-bugs at hussar dot me.uk> ---
Appears to be fixed in g++ v9.3.0.