This is the mail archive of the
mailing list for the GCC project.
Re: C++/ObjC identifiers charset conversion cleanup
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 09 May 2009 19:35:29 -0500
- Subject: Re: C++/ObjC identifiers charset conversion cleanup
- References: <Pine.LNX.firstname.lastname@example.org>
"Joseph S. Myers" <email@example.com> writes:
| This patch prepares identifiers handling for C++ and ObjC - except for
| the ObjC -gen-decls option - for extended identifiers.
| The ObjC changes are straightforward, and the changes to
| objc_lookup_protocol to have two full diagnostic sentences instead of
| building up a diagnostic from fragments make the code simpler as well
| as making it i18n-friendly and making it work with extended
| identifiers. The C++ changes are more complicated. The basic issue
| here is that the same C++ pretty printing code is used for:
| * Diagnostics (where identifiers should be translated to the locale
| (LC_CTYPE) character set, and various English fragments used in
| pretty printing should be translated to the locale (LC_MESSAGES)
| * Debugging dumps (which are not generally locale-dependent, are
| intended for GCC developers only and do not have messages marked for
| translation, so avoiding both the above translations is best).
| * __PRETTY_FUNCTION__ (via cxx_printable_name), which must not depend
| on the user's locale and so must also avoid these translations.
| It isn't always clear exactly which parts of the pretty-printing code
| are accessible in each case. The approach I chose was to add a flag
| to the base pretty-printer for whether identifiers should be
| translated to the locale character set, then use it also to control
| whether English fragments are translated to the locale language; then
| only a limited number of places that initialize a pretty-printer for
| non-diagnostics purposes need to change (and some of those places need
| versions for both diagnostics and non-diagnostics uses).
I think the flag is effectively the way to go. Hopefully, we don't or
won't forget to set it in the appropriate circumstances.
| The following areas outside of cpplib still need to be fixed for
| extended identifiers: C -aux-info, ObjC -gen-decls, identifiers
| handling in gcc/config/, use of DW_AT_use_UTF8 in DWARF-3 debug info
| for compilation units built with extended identifiers enabled.
| Bootstrapped with no regressions on x86_64-unknown-linux-gnu,
| including Obj-C++. OK to commit?