zsh-4.3.2 fails to run .zcompdump when an "alias -g" is in it

[Zrajm C Akfohg <zrajmc@xxxxxxxxx>]

I reported this bug via the Gentoo Bugzilla in November 2006, however noone
there [http://bugs.gentoo.org/show_bug.cgi?id=155525] has commented on it, much
less passed it on "upstream", as they claim they do. So now I've tried to track
down the relevant ppl and direct by bugreport directly to you. I cincerely hope
this is the right place for this stuff. Here is a copy of my original bug report
on bugs.gentoo.org:


A couple of zsh versions ago I started to sometimes get the following error
message each time I opened up a new (z)shell:

    /home/zrajm/.zcompdump:3: bad set of key/value pairs for associative array

And after this message, all tab completion stops working in that shell. Once
the problem has appeared, all new shells get the exact same symptoms. If I
erase the ~/.zcompdump file, however, the shell I start after that will work
just fine (but start a little slow, since it is generating a new .zcompdump).
Upon starting a new shell after that, though, the problem is back.

I.e. *all* shells which source an existing .zcompdump show this problem.

At the time I did some experimenting, and found that if I removed the line "cp
_cp" inside the associative array assignment of _comps the problem I had went
away.

Today I realized that this might have something with the global alias "cp" that
I have. And sure enough, if I remove the line

     alias -g cp='cp -b'

from my .zshrc the problem goes away.

HOWEVER instead of removing the alias, I can also edit the .zcompdump file,
quoting the word "cp" on the faulty line. If I replace

_comps=(
   ...
   cp _cp
   ...
)

with

_comps=(
   ...
   'cp' _cp
   ...
)

the problem goes away completely. -- Until zsh generates a new (faulty)
.zcompdump file.

Thus, zsh should generate a .zcompdump file in which the keys in all
associative arrays are quoted, to avoid having them expanded as aliases.