help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Peter Stephenson <p.w.stephenson@ntlworld.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Named reference typos & misc.
Date: Tue, 14 Feb 2023 12:00:54 -0800	[thread overview]
Message-ID: <CAH+w=7aRann+SXDjNwQP3dh=_-e9etrhms5cL-MQp-03KWtp1Q@mail.gmail.com> (raw)
In-Reply-To: <1911575874.92635.1676392609186@mail.virginmedia.com>

On Tue, Feb 14, 2023 at 8:37 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On 14/02/2023 16:14 Bart Schaefer <schaefer@brasslantern.com> 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}

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]

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).

> 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

  reply	other threads:[~2023-02-14 20:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14  2:08 Bart Schaefer
2023-02-14 14:46 ` Peter Stephenson
2023-02-14 16:14   ` Bart Schaefer
2023-02-14 16:36     ` Peter Stephenson
2023-02-14 20:00       ` Bart Schaefer [this message]
2023-02-15  1:39         ` Bart Schaefer
2023-02-16 15:29           ` zmodload (-u?) changing options (was Re: [PATCH] Named reference typos & misc.) Bart Schaefer
2023-02-16 15:52             ` Peter Stephenson
2023-02-16 18:17               ` Bart Schaefer
2023-02-16 19:28                 ` Bart Schaefer
2023-02-16 23:10                 ` Bart Schaefer
2023-02-21 11:47                 ` Peter Stephenson
2023-02-21 12:11                   ` Peter Stephenson
2023-02-21 15:57                     ` Bart Schaefer
2023-02-15 10:12         ` [PATCH] Named reference typos & misc Peter Stephenson
2023-02-15 10:36           ` Peter Stephenson
2023-02-15 14:58             ` Bart Schaefer

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7aRann+SXDjNwQP3dh=_-e9etrhms5cL-MQp-03KWtp1Q@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=p.w.stephenson@ntlworld.com \
    --cc=zsh-workers@zsh.org \


* 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.
Code repositories for project(s) associated with this public inbox


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).