Okay, this is a shortcut. Our coding style says that error
messages are exempt from '80 chars long lines' rule. But in the
very same paragraph it is said that all error messages need to be
marked for translation (as they might be presented to user).

Therefore, the syntax-check rule can check if _("...") is
formatted on one line. With exception of _("...\n" ...) (e.g.
various outputs from helper binaries like leaseshelper,
sshhelper, or daemons like lockd, logd). I believe nobody would
chose a substring that contains '\n' for git grep-ping the error
message.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 build-aux/syntax-check.mk | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 64c1e2773e..618c0546aa 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -440,6 +440,11 @@ sc_prohibit_newline_at_end_of_diagnostic:
 	  && { echo 'newline at end of message(s)' 1>&2; \
 	    exit 1; } || :
 
+sc_prohibit_error_message_on_multiple_lines:
+	@prohibit='[^N]_\(".*[^\\n]"$$' \
+	halt='found error message on multiple lines' \
+	$(_sc_search_regexp)
+
 # Look for diagnostics that lack a % in the format string, except that we
 # allow VIR_ERROR to do this, and ignore functions that take a single
 # string rather than a format argument.
@@ -1386,6 +1391,9 @@ exclude_file_name_regexp--sc_prohibit_raw_virclassnew = \
 exclude_file_name_regexp--sc_prohibit_newline_at_end_of_diagnostic = \
   ^src/rpc/gendispatch\.pl$$
 
+exclude_file_name_regexp--sc_prohibit_error_message_on_multiple_lines = \
+  ^(build-aux/syntax-check\.mk|docs/coding-style.rst)
+
 exclude_file_name_regexp--sc_prohibit_nonreentrant = \
   ^((po|tests|examples)/|docs/.*(py|js|html\.in|.rst)|run.in$$|tools/wireshark/util/genxdrstub\.pl|tools/virt-login-shell\.c$$)
 
-- 
2.41.0

On Mon, Sep 04, 2023 at 10:31:48 +0200, Michal Privoznik wrote:
> Okay, this is a shortcut. Our coding style says that error
> messages are exempt from '80 chars long lines' rule. But in the
> very same paragraph it is said that all error messages need to be
> marked for translation (as they might be presented to user).
> 
> Therefore, the syntax-check rule can check if _("...") is
> formatted on one line. With exception of _("...\n" ...) (e.g.
> various outputs from helper binaries like leaseshelper,
> sshhelper, or daemons like lockd, logd). I believe nobody would
> chose a substring that contains '\n' for git grep-ping the error
> message.
> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  build-aux/syntax-check.mk | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
> index 64c1e2773e..618c0546aa 100644
> --- a/build-aux/syntax-check.mk
> +++ b/build-aux/syntax-check.mk
> @@ -440,6 +440,11 @@ sc_prohibit_newline_at_end_of_diagnostic:
>  	  && { echo 'newline at end of message(s)' 1>&2; \
>  	    exit 1; } || :
>  
> +sc_prohibit_error_message_on_multiple_lines:
> +	@prohibit='[^N]_\(".*[^\\n]"$$' \

This doesn't work as you expect it to work, because the [] operator(?)
in regex defines a character set to match . Thus you are exempting any
message which ends with a backslash _OR_ with an 'n' rather than ending
with "\n".

On Mon, Sep 04, 2023 at 10:46:17 +0200, Peter Krempa wrote:
> On Mon, Sep 04, 2023 at 10:31:48 +0200, Michal Privoznik wrote:
> > Okay, this is a shortcut. Our coding style says that error
> > messages are exempt from '80 chars long lines' rule. But in the
> > very same paragraph it is said that all error messages need to be
> > marked for translation (as they might be presented to user).
> > 
> > Therefore, the syntax-check rule can check if _("...") is
> > formatted on one line. With exception of _("...\n" ...) (e.g.
> > various outputs from helper binaries like leaseshelper,
> > sshhelper, or daemons like lockd, logd). I believe nobody would
> > chose a substring that contains '\n' for git grep-ping the error
> > message.
> > 
> > Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> > ---
> >  build-aux/syntax-check.mk | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
> > index 64c1e2773e..618c0546aa 100644
> > --- a/build-aux/syntax-check.mk
> > +++ b/build-aux/syntax-check.mk
> > @@ -440,6 +440,11 @@ sc_prohibit_newline_at_end_of_diagnostic:
> >  	  && { echo 'newline at end of message(s)' 1>&2; \
> >  	    exit 1; } || :
> >  
> > +sc_prohibit_error_message_on_multiple_lines:
> > +	@prohibit='[^N]_\(".*[^\\n]"$$' \
> 
> This doesn't work as you expect it to work, because the [] operator(?)
> in regex defines a character set to match . Thus you are exempting any
> message which ends with a backslash _OR_ with an 'n' rather than ending
> with "\n".

The simplest solution (rather than trying to fiddle with negative
lookahead) seems to be:

sc_prohibit_error_message_on_multiple_lines:
	@prohibit='[^N]_\(".*"$$' \
    exclude='\\n"$$' \
	halt='found error message on multiple lines' \
	$(_sc_search_regexp)

And perhaps adding a comment explaining what it actually does, so the
next guy doesn't have to try to understand it.

With the above tweak and comment added:

Reviewed-by: Peter Krempa <pkrempa@redhat.com>