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(a)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(a)redhat.com>