ERR_RETURN ignored in 'if' in a source'd file [FIXED]

Hi all,

I recently hit a bug in zsh 5.9 that has since been fixed in the main git
branch, so I thought I'd describe the bug here in case anyone else runs into
it.

The example is:

#!/usr/bin/env zsh
foo(){
    setopt err_return
    source <(echo 'if true; then return 42; fi')
    echo "This line is printed by zsh 5.9 (but it shouldn't be)."
}
foo

I ran git-bisect and found that this bug was fixed in:

commit f253ea6b9d14901e24fa6a376936effad9e6547b
Author: Philippe Altherr [email redacted]
Date:   Sat Dec 3 21:14:26 2022 -0800

    51076: fix ERR_EXIT when used with "eval" or "source"; documentary
comments

In the scripts i was originally working on, the source'd file is named
'foo.parse-arguments', which parses arguments that the user provides to `foo`,
and which contains an invocation of `zparseopts` (which is about a half-page
long), followed by several checks to make sure that the arguments are
reasonable.

I `source` it so that the local parameters defined in `foo.parse-arguments`
are introduced into the scope of `foo`. And because `foo.parse-arguments`
returns non-zero in the event of a usage error, everything in `foo` after the
`source` invocation can just use those option parameters without any other
checks (and that helps to keep `foo` reasonably-sized).

...But that all depended on ERR_RETURN working as in the example above. So I'm
very happy to find that this bug was already fixed!

Many thanks to Philippe Altherr for all the ERR_RETURN/ERR_EXIT fixes, and
also, thanks to all maintainers!

I've been using zsh for at least 15 years. I don't recall hitting any other
zsh bugs in that time, and I cannot say the same of most of the tools that I
use on a daily basis. Well done, all!

--James