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@xxxxxxxxxx>
> > ---
> > 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@xxxxxxxxxx>
