On Mon, 14 Oct 2019, Martin Sebor wrote: > On 10/14/19 4:03 PM, Joseph Myers wrote: > > How does this interact with translation? > > > > My expectation would be that in user code, the message is taken literally > > as-is; it is not looked up in the GCC message catalog even if it is > > identical to some GCC diagnostic. However, when used internally for GCC > > diagnostics, they should be translated, meaning the translation for GCC > > diagnostics using this mechanism should occur before the built-in call is > > stored in the IR. > > Right, that would make sense. Does something make you think it will > be hard to do?
No. I'd expect the code generating the IR from GCC diagnostics should arrange for the message to be translated first (while in the case of __builtin_warning in user code, it would not be translated), and the code subsequently using the IR to use diagnostic_set_info_translated or functions that end up calling it without trying to translate. > I suppose we'll need to make sure these strings are translated just > like for warning_at. Come to think of it, how does it happen there? > Is it just via the __gcc_*diag__ attributes? Those attributes control the checks done by the compiler used to build GCC. The naming of parameters ending in "msgid" controls extraction for translation (see ABOUT-GCC-NLS). Thus N_ and G_ provide for extraction without actually translating at the call site (if the string isn't being passed directly as a so-named parameter of a function), while _ provides for extraction with translation occurring at the call site. -- Joseph S. Myers jos...@codesourcery.com
