Re: workers/40626 (commit 6c476c22) causes multiple test failures

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Tue, Feb 28, 2017 at 08:38:55 -0800:
> On Feb 28,  7:45am, Daniel Shahaf wrote:
> } Subject: Re: workers/40626 (commit 6c476c22) causes multiple test failures
> }
> } Bart Schaefer wrote on Sun, Feb 26, 2017 at 11:42:16 -0800:
> } > I suspect this is what comes of some attempt to optimize assignments.
> 
> It occurs to me that $options et al. predate the += syntax, so this may
> just have been overlooked when adding array-append.
> 
> } For future reference, James (who reported the original bug offlist) has
> } since reported another symptom:
> } 
> } % autoload -Uz compinit; compinit; setopt listambiguous; options+=()
> 
> So here's my question ... why would you ever attempt to append to the
> options parameter, empty append or otherwise?

To set multiple options at once:

    local -a options_to_set=( printexitvalue on warncreateglobal off )
    options+=( $options_to_set )

I'm sure you can imagine how $options_to_set might be empty in one
codepath but not in another.

(The actual reason I used an empty append in the reproduction recipe
was for the sake of minimality, but that's somewhat tangential.)

> The options hash always
> contains all possible valid keys; you can't add/delete a key; you can't
> duplicate a key; so it absolutely never makes sense to append options.
> 
> I was half of a mind to flat out make it an error, as these are ...
> 
> torch% options[bogus]=on      
> zsh: no such option: bogus
> torch% options[shwordsplit]=
> zsh: invalid value: 
> 

The append syntax doesn't accept these either:

    % options+=( bogus on )
    zsh: no such option: bogus
    % options+=( shwordsplit '' ) 
    zsh: invalid value: 
    % 

I don't think a change is needed.

> ... until I realized that all the other zsh/parameter hashes had the
> same problem and some of them *could* sensibly be appended.

Cheers,

Daniel