Re: [PATCH] Named reference typos & misc.

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Feb 14, 2023 at 8:37 AM Peter Stephenson
<p.w.stephenson@xxxxxxxxxxxx> wrote:
>
> On 14/02/2023 16:14 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> >
> > I get a passed test with or without the "unsetopt typeset_to_unset".
> >
> > Is there some way this could be platform-dependent?
>
> Here's a minimal case:

I can reproduce the (lack of) error message with your minimal case.

Gets odder.  I added
  set -o
to the test (otherwise exactly as pushed) and the output includes

+typesetsilent         off
+typesettounset        off
+nounset               off

I've no idea how/where it gets turned off, though.

If I strip down K01 to just that single test, the error message
doesn't happen (test fails).

If I make setopt into a wrapper function in the %prep section, test
fails, but I don't see any change to that option emerging from the
wrapper function (directs to /dev/tty).

If I remove the setopt from %prep entirely, the other tests that rely
on it, fail, so it IS set.

By binary search, I found the option state changes for me after this test:

 typeset ptr2=var2
 typeset var2=GLOBAL
 () {
   typeset -n ptr1=ptr2
   typeset ptr2=var1
   typeset var1=VAR1
   typeset var2=VAR2
   print -r -- ${(P)ptr1}
 }
0:
>VAR2

For which I forgot to write a description, but it's supposed to check
order-of-evaluation for namerefs and (P).

Running that test standalone does not cause the option to change:

Src/zsh -f =(<<\EOF
setopt localloops
() {
setopt typeset_to_unset
typeset ptr2=var2
 typeset var2=GLOBAL
 () {
   typeset -n ptr1=ptr2
   typeset ptr2=var1
   typeset var1=VAR1
   typeset var2=VAR2
   print -r -- ${(P)ptr1}
 }
print $options[typesettounset]
}
EOF
)
VAR2
on

I have no idea how to debug this.  Thoughts?  I would suspect it's
more related to the test harness than to the named reference changes.
I tried removing the EXECOPT frobbing around subscript evaluation,
that made no difference (except for the test specifically about that).

Unrelated:
> I kept the loop in the function to avoid a (correct) additional warning
> message setting the global variable ref in the loop.  I don't know if
> setting ref in a for loop should actually elide that message, which
> is a completely separate issue.

You mean an assignment within the loop, while "ref" already points out
of it?  I would think that'd be expected to trigger warn_create_global
instead,