Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x <waffl3x@protonmail.com>]

> (Jakub)
> There are different kinds of format strings in GCC, the most common
> are the gcc-internal-format strings. If you call a function which
> is expected to take such translatable format string (in particular
> a function which takes a gmsgid named argument like error, error_at,
> pedwarn, warning_at, ...) and pass a string literal to that function,
> nothing needs to be marked in a special way, both gcc/po/exgettext
> is able to collect such literals into gcc/po/gcc.pot for translations
> and the function is supposed to use gettext etc. to translate it
> - e.g. see diagnostic_set_info using (gmsgid) for that.
> But, if there is e.g. a temporary pointer var which points to format
> strings and only that is eventually passed to the diagnostic functions,
> gcc/po/exgettext won't be able to collect such literals, which is where
> the G() macro comes into play and one marks the string as
> gcc-internal-format with it; the translation is still handled by the
> diagnostic function at runtime. The N_() macro is similar but for c-format
> strings instead. The _() macro both collects for translations if it is
> used with string literal, and expands to gettext call to translate it at
> runtime, which is something that should be avoided if something translates
> it again.

> (Jason)
> The protocol is described in gcc/ABOUT-GCC-NLS. In general, "strings"
> passed directly to a diagnostic function don't need any decoration, but
> if they're assigned to a variable first, they need G_() so they're
> recognized as diagnostic strings to be added to the translation table.

I read this last night and decided to sleep on it hoping it would make
more sense now. I was going to write about how I'm still confused but I
think it just clicked for me. I somehow didn't make the connection that
any kind of of expression (like a conditional) is going to require it's
use. I guess I kept thinking "but they aren't being assigned to a
variable" but I get it now, it's when the strings aren't passed
DIRECTLY into the diagnostic function.

> (Jakub)
> And another i18n rule is that one shouldn't try to construct diagnostic
> messages from parts of english sentences, it is fine to fill in with %s/%qs
> etc. language keywords etc. but otherwise the format string should contain
> the whole diagnostic line, so that translators can reorder the words etc.

> (Jason)
> The () macro is used for strings that are going to be passed to a %s,
> but better to avoid doing that for strings that need translation. N()
> is (rarely) used for strings that aren't diagnostic format strings, but
> get passed to another function that passes them to _().

Okay so taking what you guys are saying here it sounds like it would be
appropriate to refactor the code I was reluctant to refactor. The code
(in grokfndecl) conditionally selects one of the two (now three with my
changes) following strings despite them being mostly identical.

"non-member function %qD cannot have cv-qualifier"
"static member function %qD cannot have cv-qualifier"
"explicit object member function %qD cannot have cv-qualifier"

From what I'm getting from what you two have said is that it would be
reasonable to instead construct a string from it's two parts, just
selecting the differing part dynamically.

"%s function %qD cannot have cv-qualifier"

Just to clarify, should I be marking the "non-member", "static member",
"explicit object member" strings with the _ macro then? I'm just not
sure since it seems like Jason is saying they shouldn't be since the
string they are being formatted into is being translated afterwards.

Also, I'm not sure what %qs is, should I be using that instead of %s
for strings?

On another topic, I have been trying to fix taking pointers to explicit
object member functions today, as I ended up breaking that when I
started setting static_function to false for them. Originally it just
worked so I haven't touched any code related to this, but now that they
aren't being treating like static member functions as much so a few
things just broke. What I'm asking myself now is whether it would be
appropriate to just opt-in to static member function behavior for this
one, and I'm not sure that would be correct.

So I started by checking what it did before I turned off the
static_function flag. It's was being passed into cp_build_addr_expr_1
as a baselink node, while regular member functions are passed in as an
offset_ref node. I then checked what the case is for static member
function, and unsurprisingly those are also handled wrapped in a
baselink node, but this raised some questions for me.

I am now trying to figure out what exactly a baselink is, and why it's
used for static member functions. My current best guess is that
method_type nodes already hold the information that a baselink does,
and that information is needed in general. If that is the case, it
might just be correct to just do the same thing for explicit object
member functions, but I wonder if there is more to it, but maybe there
isn't. It worked just fine before when the static_function was still
being set after all.

Any insight on this is appreciated.

Alex