https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980
Jason changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980
--- Comment #6 from Jason ---
And lo! Finally! This appears to have been done in g++ v9.3.0. Amazing! Huzzah!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59980
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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.
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
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 's1t2' or 's2e2::t4', which is clearer (to me).
I agree
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