From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <ericsunshine@charter.net>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 1/2] chainlint: make error messages self-explanatory
Date: Thu, 29 Aug 2024 08:39:13 -0700 [thread overview]
Message-ID: <xmqq7cbzxrry.fsf@gitster.g> (raw)
In-Reply-To: <20240829091625.41297-2-ericsunshine@charter.net> (Eric Sunshine's message of "Thu, 29 Aug 2024 05:16:24 -0400")
Eric Sunshine <ericsunshine@charter.net> writes:
> "?!LOOP?!" case is particularly serious since it is likely that some
> newcomers are unaware that shell loops do not terminate automatically
> upon error, and it is more difficult for a newcomer to figure out how to
> correct the problem by examining surrounding code since `|| return 1`
> appears in test scrips relatively infrequently (compared, for instance,
> with &&-chaining).
"scrips" -> "scripts"
I'd prefer to see "some newcomes are unaware that" part rewritten
and toned down, as it is not our primary business to help total
newbies to learn shells, it certainly is not what the chain lint
checker should bend over backwards to do.
... particularly serious, as it does not convey that returning
control with "|| return 1" (or "|| exit 1" from a subshell)
immediately after we detect an error is the canonical way we
chose in this project to handle errors in a loop. Because it
happens relatively infrequently, this norm is harder to figure
out for a new person on their own than other patterns (like
&&-chaining).
> Address these shortcomings by emitting human-consumable messages which
> both explain the problem and give a strong hint about how to correct it.
"consumable" -> "readable".
>
> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
> ...
> # Input arguments are pathnames of shell scripts containing test definitions,
> # or globs referencing a collection of scripts. For each problem discovered,
> # the pathname of the script containing the test is printed along with the test
> -# name and the test body with a `?!FOO?!` annotation at the location of each
> +# name and the test body with a `?!ERR?!` annotation at the location of each
> # detected problem, where "FOO" is a tag such as "AMP" which indicates a broken
"FOO" -> "ERR"?
> @@ -619,6 +623,15 @@ sub unwrap {
> return $s
> }
>
> +sub format_problem {
> + local $_ = shift;
> + /^AMP$/ && return "missing '&&'";
> + /^LOOPRETURN$/ && return "missing '|| return 1'";
> + /^LOOPEXIT$/ && return "missing '|| exit 1'";
> + /^HEREDOC$/ && return 'unclosed heredoc';
> + die("unrecognized problem type '$_'\n");
> +}
> +
> sub check_test {
> my $self = shift @_;
> my $title = unwrap(shift @_);
> @@ -641,7 +654,8 @@ sub check_test {
> for (sort {$a->[1]->[2] <=> $b->[1]->[2]} @$problems) {
> my ($label, $token) = @$_;
> my $pos = $token->[2];
> - $checked .= substr($body, $start, $pos - $start) . " ?!$label?! ";
> + my $err = format_problem($label, $token);
> + $checked .= substr($body, $start, $pos - $start) . " ?!ERR $err?! ";
> $start = $pos;
> }
> $checked .= substr($body, $start);
With the hunks omitted before the above two that let us tell between
RETURN vs EXIT, the above two makes the problems much easier to
read.
All the "examples" (self tests) and changes to them looked sensible.
Thanks.
next prev parent reply other threads:[~2024-08-29 15:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 9:16 [PATCH 0/2] make chainlint output more newcomer-friendly Eric Sunshine
2024-08-29 9:16 ` [PATCH 1/2] chainlint: make error messages self-explanatory Eric Sunshine
2024-08-29 10:03 ` Patrick Steinhardt
2024-08-29 17:07 ` Jeff King
2024-08-29 18:10 ` Eric Sunshine
2024-08-29 18:01 ` Eric Sunshine
2024-08-29 15:39 ` Junio C Hamano [this message]
2024-08-29 22:04 ` Eric Sunshine
2024-08-30 18:41 ` Junio C Hamano
2024-08-29 9:16 ` [PATCH 2/2] chainlint: reduce annotation noise-factor Eric Sunshine
2024-08-29 10:03 ` Patrick Steinhardt
2024-08-29 17:10 ` Jeff King
2024-08-29 18:37 ` Eric Sunshine
2024-08-29 18:28 ` Eric Sunshine
2024-08-29 15:55 ` Junio C Hamano
2024-08-30 23:30 ` Eric Sunshine
2024-08-30 23:51 ` Junio C Hamano
2024-09-10 4:10 ` [PATCH v2 0/3] make chainlint output more newcomer-friendly Eric Sunshine
2024-09-10 4:10 ` [PATCH v2 1/3] chainlint: don't be fooled by "?!...?!" in test body Eric Sunshine
2024-09-10 16:48 ` Junio C Hamano
2024-09-10 4:10 ` [PATCH v2 2/3] chainlint: make error messages self-explanatory Eric Sunshine
2024-09-10 7:48 ` Patrick Steinhardt
2024-09-10 4:10 ` [PATCH v2 3/3] chainlint: reduce annotation noise-factor Eric Sunshine
2024-09-10 7:48 ` Patrick Steinhardt
2024-09-10 8:14 ` Eric Sunshine
2024-09-10 15:42 ` Junio C Hamano
2024-09-10 22:17 ` Eric Sunshine
2024-09-10 6:44 ` [PATCH v2 0/3] make chainlint output more newcomer-friendly Jeff King
2024-09-10 17:31 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7cbzxrry.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ericsunshine@charter.net \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).